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ABSTRACT 


Modem  computing  advances  allow  the  aerospace  controls  engineer  the  ability 
to  design,  test,  and  implement  automatic  control  systems  for  air  vehicles  with  breath 
taking  speed  and  accuracy.  This  work  examines  the  automation  of  the  hardware- 
in-the-loop  testing  and  implementaic'  -t.  f  ^nomous  controllers  for  Unmanned  Air 
Vehicles.  Extraordinary  interest  is  genera  ^  in  this  subject  considering  automation 
results  in  hardware-in-the-loop  testing  within  days  of  completing  a  controller  design. 
The  entire  automation  process  is  presented,  from  design  of  the  controller  to  imple¬ 
mentation  on  a  particular  control  platform  to  hardware-in-the-loop  testing  of  the 
controller.  This  accomplishes  control  design  and  implemention  in  a  matter  of  months 
compared  to  a  few  years  or  more  before  automation. 
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I.  INTRODUCTION 


The  aeronautical  controls  engineer  of  the  90’s  can  design  a  dynamic  aircraft 
model,  verify  its  accuracy,  design  a  control  system,  and  implement  the  controller  on 
a  computer  in  a  matter  of  a  few  months.  Application  software  tools  such  as  MaTLAB 
with  SlMULlNK  and  MATRIX*  with  SystemBuild  allow  the  design  to  be  completed 
and  tested  at  the  block  diagram  level.  In  particular,  Autogen  and  AC100  products 
developed  by  Integrated  Systems,  Incorporated  allow  for  direct  conversion  of  the 
block  diagram  to  a  fully  implemented  control  system.  This  system  can  be  tested 
real-time  with  hardware-in-the-loop  while  recording  any  or  all  of  the  state  variables 
to  verify  performance.  Before  discussing  the  automation  of  the  design  process  in 
detail,  a  brief  outline  of  each  step  follows. 

The  first  step  in  the  design  process  is  to  create  a  high  fidelity  nonlinear  model 
of  the  aircraft  which  can  be  reliably  trimmed  and  linearized  throughout  the  full 
spectrum  of  required  flight  conditions.  Such  modeling  is  completed  in  four  stages: 

•  Developing  the  equations  of  motion.  Sum  all  of  the  forces  and  moments  involved 
and  write  the  equations  in  terms  of  states  to  allow  for  easy  convertion  into  a 
block  diagram. 

•  Creating  a  nonlinear  model.  Create  a  block  diagram  representation  of  these 
equations. 

•  Creating  a  linear  model.  Trim  the  nonlinear  model  about  the  desired  trim  point 
and  then  linearize  the  model  to  obtain  a  linear  model. 
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•  Validating  the  model.  Use  the  data  from  an  independent  source  to  validate  the 
model. 

The  next  step  is  to  design  a  feedback  controller.  This  is  typically  an  itera¬ 
tive  procedure  beginning  with  the  design  requirements.  Usually  requirements  will 
be  placed  by  the  designer  in  terms  of  response  time  and  overshoot  for  the  desired 
controller.  For  example  a  heading  controller  may  be  required  to  achieve  a  ten  degree 
heading  change  within  30  seconds  and  have  a  maximum  overshoot  of  one  degree. 
With  the  requirements  on  hand,  the  control  design  steps  are: 

•  Building  a  control  synthesis  model.  The  designer  chooses  which  sensors  to  use 
and  creates  a  synthesis  model  with  the  desired  command  inputs  using  the  linear 
model. 

•  Computing  the  control  gain.  A  cost  function  is  defined  by  the  designer  de¬ 
pending  on  the  specified  requirements  and  the  method  chcsen  for  computing 
the  controller.  The  control  gain  is  then  calculated.  The  methods  for  computing 
this  gain  include: 

-  Linear  Quadratic  Regulator  Theory 

-  Hoo  Theory 

•  Check  the  command  and  control  loop  bandwidth:  The  bandwidth  is  plotted 
for  each  of  the  command  loops  and  checked  against  the  specified  requirements. 
The  control  loop  bandwidth  is  also  checked  and  compared  to  the  bandwidth  of 
the  chosen  actuators. 

The  cost  function  defined  above  includes  some  weighting  factors.  These  are  the 
design  knobs  which  the  designer  uses  to  create  the  desired  controller.  If  the  control 
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and/or  command  bandwidths  are  too  large  or  too  small,  the  designer  adjusts  these 
weights  and  re-computes  the  control  gain.  This  typically  involves  many  iterations. 
The  designer  may  also  find  it  necessary  to  move  the  zeros  placed  in  the  synthesis 
model  and  restart  the  iterations  from  that  point. 

The  next  step  in  the  design  process  is  to  test  the  feedback  system.  SlMULINK 
and  SystemBuild  have  built  in  capabilities  for  performing  these  tests.  The  first  test  is 
to  close  the  loop  with  the  linear  model  and  the  controller.  The  resulting  closed-loop 
system  is  then  tested.  Next  the  controller  is  connected  with  the  nonlinear  model  and 
tested. 

An  important  step  in  the  testing  process  is  to  develop  an  accurate  model  of  the 
actuators.  If  the  actuators  are  not  modeled  well,  the  software  test  of  the  controller 
may  indicate  that  the  controller  works  as  designed  while  an  hardware-in-the-loop 
test  may  show  that  the  feedback  system  is  unstable.  This  is  usually  caused  by  the 
actuators  not  being  able  to  respond  fast  enough  to  commands. 

Once  an  accurate  model  of  the  actuators  has  been  developed,  the  closed  loop 
software  test  is  repeated  with  the  actuator  models  in  the  loop.  If  the  actuator  models 
are  acurate  and  the  controller  design  is  correct,  there  should  not  be  an  apparent 
difference  in  the  performance  of  the  controller. 

The  designed  controller  must  be  implemented  on  a  platform  capable  of  produc¬ 
ing  the  required  control  signals  and  reading  the  given  sensor  outputs.  Since  personal 
computers,  or  PCs  have  become  very  cost  effective,  the  typical  controller  implementa¬ 
tion  is  a  PC  microprocessor  with  input/output,  or  I/O  cards.  The  I/O  cards  available 
can  produce  or  read  analog  voltages,  pulse  width  modulated,  or  PWM  signals,  and 
serial  communications  to  name  a  few.  The  control  algorithm  is  then  programmed 
using  a  high  level  language  such  as  C  or  FORTRAN  and  then  compiled  to  run  on 
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the  chosen  PC.  During  programming,  careful  consideration  must  be  given  to  initial¬ 
izing  and  using  the  I/O  cards.  Timing  is  the  most  critical  part  of  the  programmed 
controller. 

The  next  step  is  hardware-in-the-loop  ,  or  HITL  simulation,  where  the  feedback 
system  is  tested  with  some  of  the  actual  hardware  which  will  be  used  to  control  the 
aircraft.  HITL  testing  is  done  in  one  or  more  stages. 

•  Actuators  and  Sensors:  The  first  stage  is  to  include  all  of  the  actuators  which 
receive  control  signals  directly,  such  as  the  elevators,  rudder,  and  ailerons.  The 
sensors  which  measure  the  results  of  these  actuators  must  also  be  included  in 
order  to  close  the  loop.  After  this  initial  test,  other  less  critical  actuators  may 
be  added. 

•  Control  Inputs  and  Sensors:  A  possible  second  stage  is  to  include  the  control 
input  device,  such  as  a  joystick  for  an  unmanned  aircraft,  into  the  loop  along 
with  the  sensors  required  to  measure  the  control  inputs. 

The  most  critical  part  of  any  hardware-in-the-loop  test  is  calibration  of  the  sen¬ 
sors.  The  controller  includes  an  algebraic  conversion  of  the  measured  sensor  outputs 
to  a  signal  that  can  be  used  directly  by  the  controller.  This  algebraic  conversion 
requires  calibration  by  determining  the  correct  conversion  constants. 

The  ultimate  test  of  a  designed  controller  is  the  flight  test.  Budget  considera¬ 
tions  demand  that  the  controller  work  perfectly  the  first  time.  The  flight  test  phase 
is  usually  performed  in  three  stages: 

•  Test  Stand:  The  first  flight  test  is  usually  done  in  a  laboratory  facility  on  a  test 
stand  which  allows  some  degree  of  movement  while  restricting  flight  so  that  the 
vehicle  can  not  be  damaged. 
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•  Tethered  Flight:  The  next  stage  is  typically  a  teathered  flight.  In  this  manner, 
an  experienced  pilot  can  be  standing  by  with  a  manual  override  switch  to  allow 
direct  manual  control  of  the  vehicle  in  the  event  of  a  problem. 

•  Actual  Flight:  The  final  and  ultimate  test  of  the  control  design  is  the  au¬ 
tonomous  flight  test. 

The  main  purpose  of  this  report  is  to  discuss  the  automation  of  the  design 
process  which  has  just  been  summarized.  The  main  tool  used  in  this  process  is 
Integrated  Systems,  Incorporated’s  AC100  package.  Once  the  designer  develops  a 
plant  model  and  a  controller  using  MATRIX*  and  SystemBuild,  AC100  can  be  used 
to  implement  and  test  the  controller  on  actual  hardware  with  a  few  pushes  of  a 
button. 
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II.  DEVELOPING  EQUATIONS  OF  MOTION 


A.  BACKGROUND 

There  are  several  unmanned  air  vehicles,  or  UAV’s,  currently  in  use  a  S. 
Two  of  these  are  discussed  in  this  report,  the  Bluebird  and  the  AROD.  The  AROD 
is  described  in  the  next  section  and  the  detailed  development  of  its  equations  of 
motion  and  computer  modeling  are  covered.  The  Bluebird  is  discussed  next.  It  is  a 
small  conventional  aircraft  acquired  as  a  test  bed  for  testing  guidance  and  navigation 
systems.  For  a  complete  description  and  the  development  of  the  equations  of  motion 
for  Bluebird,  see  [Ref.  1]. 

B.  DESCRIPTION  OF  AROD 

The  Airborne  Remotely  Operated  Device,  AROD  is  a  vertical  take-off  and  land¬ 
ing,  VTOL,  aircraft  originally  designed  by  Sandia  Research  Laboratory  in  Albu¬ 
querque,  New  Mexico.  The  AROD  has  been  the  subject  of  several  theses  at  NPS  and 
this  report  expands  on  the  work  started  by  those  individuals.  For  a  detailed  descrip¬ 
tion  of  AROD  refer  to  [Ref.  2,  3]  and  the  Sandia  Lab  papers  [Ref.  4,  5]  as  well  as 
the  references  therein.  The  AROD  is  shown  in  Figure  2.1  and  its  characteristics  are 
tabulated  in  Table  2.1. 

A  combination  of  the  control  vanes  are  used  to  exert  the  desired  control  forces 
on  the  AROD.  Roll  control  is  obtained  by  deflecting  all  four  vanes  in  the  opposite 
direction  of  the  desired  roll.  Pitch  and  yaw  are  obtained  by  deflecting  the  pair  of 
vanes  in  the  y  and  z  planes  respectively.  The  numbering  of  the  vanes  is  shown  in 
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Figure  2.1:  Airborne  Remotely  Operated  Device,  AROD 

Figure  2.2  and  the  combinations  of  vanes  required  for  roll,  pitch  and  yaw  are  given 
in  Table  2.2. 

There  are  three  dynamic  coupling  effects  which  must  be  considered  when  de¬ 
signing  a  control  system  for  AROD.  The  first  is  the  gyroscopic  coupling  due  to  the 
large  angular  momentum  of  the  propeller.  Another  dynamic  coupling  exists  between 
the  vehicle  attitude  and  the  altitude-rate  since  thrust  vectoring  is  required  for  trans¬ 
lational  movement.  This  coupling  is  depicted  in  Figure  2.3.  The  third  effect  is  caused 
by  the  propeller.  As  the  air  is  accelerated  through  the  propeller,  it  is  also  deflected 


TABLE  2.1:  PHYSICAL  CHARACTERISTICS  OF  AROD 


Inlet  Diameter,  A 

29.25  in 

Propeller  Radius,  R 

12  in 

Exit  Radius 

23.375  in 

Inlet  Area  Ratio 

1.219 

Exit  Area  Ratio 

1.115 

Exterior  Contour 

Tapered  Rear 

Propeller  Location,  %  chord 

25  % 

Number  of  Blades 

3 

Engine  Speed,  Max. 

8000  rpm 

Engine  Speed,  Nom. 

■KmllmflHl 

Tip  Speed,  Max. 

838  fpm 

Tip  Speed,  Nom. 

680  fpm 

Power  Loading,  — 

7.25  HP/p 

Mass  Moment  of  Inertia,  Ix 

Mass  Moment  of  Inertia,  Iy 

urmegmai 

Mass  Moment  of  Inertia,  12 

1.6147  slug  —  p 

Prop  Mass  Moment  of  Inertia,  Irx 

0.0311  slug-  p 

Prop  Mass  Moment  of  Inertia,  Iry 

Prop  Mass  Moment  of  Inertia,  ITZ 

0.0067  slug  -  p 

TABLE  2.2:  VANE  DEFLECTION  COMBINATIONS  FOR  POSITIVE  ANGLES 


Vane  Combination 

Roll,  $ 

V\  +  V2  4-  V3  +  V4 

Pitch,  0 

v2-v4 

Yaw,  $ 

Vi  -  v3 

slightly  causing  a  swirl  effect.  The  result  is  that  the  air  mass  strikes  the  control  vanes 
at  an  angle  proportional  to  the  angular  rate  of  the  propeller.  This  creates  a  rolling 
moment  which  is  dependent  on  the  throttle  input. 
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Figure  2.2:  AROD  Direction  of  Positive  Vane  Deflections 

C.  EQUATIONS  OF  MOTION 
1.  Notation 


The  notation  used  in  this  report  is  consistent  with  the  previous  work  on  the 
AROD,  see  [Ref.  2]  and  references  therein.  Consider  Figure  2.4,  here: 


{A}  represents  the  coordinate  system  with  basis  vectors,  XA,yA ,  and  za- 
aPq  represents  the  position  of  point  Q,  expressed  in  {A}. 

AVq  represents  the  velocity  of  point  Q,  measured  in  {A}  and  expressed  in  {A}. 
b(aVq)  represents  the  velocity  of  point  Q,  measured  in  {A},  and  expressed  in 

{B}. 


gR  is  a  rotation  matrix  from  {B}  to  {A},  also  called  a  direction  cosine  matrix. 
A  free  vector  in  one  coordinate  system,  is  a  vector  that  can  be  moved  parallel 
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T 


T 


All  thrust 
available 
is  used  for 
lift. 


T*cos('F)  is 
used  for  lift 
while 

T*sin('F)  is 
used  to  move 
in  y  direction 


Figure  2.3:  Coupling  Between  Altitude  and  Attitude 


to  itself  without  change.  As  a  result,  it  can  be  expressed  in  another  coordinate 
system  by  using  the  rotation  matrix.  For  example: 


A(BVq)  =  iR  ('%) 


•  aQb  is  the  angular  velocity  of  the  {5}  coordinate  system  with  respect  to  {A}, 
and  expressed  in  {A}. 

•  B(Aflg)  is  the  angular  velocity  of  {B},  with  respect  to  {A},  and  expressed  in 
{Bj. 

•  Additional  information  can  be  added  to  the  subscripts  i.e.,  aPbo  is  the  position 
of  the  origin  of  {5},  expressed  in  {A}. 

2.  Coordinate  Systems 


In  order  to  derive  equations  of  motion  for  a  rigid  airplane,  the  following 
coordinate  systems  and  assumptions  will  be  used: 
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Figure  2.4:  Relative  Position  of  Coordinate  Systems 

•  {U}  represents  the  inertial  tangent  plane  coordinate  system  attached  to  Earth. 

•  {B}  represents  the  body  fixed  coordinate  system. 

•  {VE}  represents  the  wind  axis  coordinate  system. 

•  All  sensors  are  located  at  the  c.g.  (  This  assumption  is  used  for  simplification 
only  and  can  be  relaxed  as  shown  in  [Ref.  2]  ) 

•  The  mass  of  the  aircraft  remains  constant. 

•  Given  a  vector  v,  its  derivative  with  respect  to  {B}  is  denoted  as  ^(u) 
and  its  derivative  with  respect  to  {(/}  is  denoted  as  (n) 


The  {B}  coordinate  system  is  a  right  handed  system  with  Xg  defined  as  the  thrust 
axis.  A  positive  roll  rate,  p,  is  clockwise  when  looking  in  the  positive  X  direction. 
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The  positive  direction  for  Vb,  the  pitch  axis,  is  out  the  right  wing  .  A  positive  pitch 
rate,  q,  is  defined  as  clockwise  looking  in  the  positive  Y  direction.  The  Zb  axis  is  the 
yaw  axis,  and  a  positive  yaw  rate,  r,  is  defined  as  clockwise,  looking  in  the  positive 
Z  direction. 

The  {IT"}  coordinate  system  is  defined  with  Xw  aligned  with  the  wind 
incident  on  the  aircraft.  The  angle  a  is  the  angle  formed  by  the  body  x-y  plane  and 
the  positive  Xw  axis.  The  angle  0  is  the  angle  formed  by  the  body  x-z  plane  and 
the  positive  Yw  axis. 

To  simplify  the  notation  in  places  where  it  becomes  cumbersome,  the  fol¬ 
lowing  definitions  are  introduced: 

•  vq  represents  the  velocity  of  an  arbitrary  point,  Q,  measured  and  expressed  in 

m. 

•  vbo  represents  the  velocity  of  the  origin  of  {£?},  measured  and  expressed  in 
{f/},  i.e.,  vVbo  =  vbo- 

•  vb  represents  the  acceleration  of  {B}  with  respect  to  {U},  measured  and  ex¬ 
pressed  in  {(/}. 

•  bvq  represents  the  velocity  of  point  Q,  measured  in  {U}  and  expressed  in  { B }, 
i.e.,  b(uVq)  =  bvq. 

•  u >b  represents  the  angular  velocity  of  {£},  measured  and  expressed  in  {£/},  i.e., 
uSIb  =  wg. 

•  bub  represents  the  angular  velocity  of  {B}  measured  in  {(/},  and  expressed  in 
{B},  i.e.,  B(uSlB)  =  Vb. 


•  0  represents  the  appropriate  size  matrix  with  all  elements  equal  to  zero. 


•  /„  represents  the  identity  matrix  of  dimension  n. 

3.  Spatial  Orientation  Using  Euler  Angles 

The  spatial  orientation  of  a  rigid  body  [Ref.  6]  can  be  defined  by  the  three 
Euler  angles,  $,  0,  and  $  called  roll,  pitch  and  yaw  and  defined  in  Figure  2.5.  The 
Euler  angles,  in  turn,  can  be  used  to  define  a  rotation  between  two  coordinate  systems. 
This  rotation  is  obtained  using  Euler’s  theorem: 

Any  number  of  rotations  about  different  axes  through  a  point  must,  in 
the  end,  remain  equivalent  to  a  single  rotation. 

For  the  case  of  conventional  aircraft,  a  3-2-1  rotation  sequence  is  used  [Ref.  7], 
where  the  aircraft  is  yawed,  pitched,  and  then  rolled.  In  this  case,  0  is  small,  and  in 
steady  state  flight  is  equal  to  the  angle  of  attack,  a.  The  angle  $  can  be  expected 
to  be  anywhere  from  ±  60  deg  in  normal  flight  and  can  be  anywhere  from  ±180  deg 
in  acrobatic  flight,  represents  the  heading  of  the  aircraft  and  of  course  can  range 
from  0  to  360  deg.  This  euler  angle  rotation  was  used  in  modeling  the  Bluebird. 

Euler  angle  rotations  have  an  inherent  singularity  point  when  considering 
euler  angular  rates.  The  singularity  point  for  a  3-2-1  rotation  is  0  =  90  deg.  There¬ 
fore,  the  adopted  convention  for  AROD  is  a  2-3-1  rotation  which  has  a  singularity 
point  at  ^  =  90  deg. 

The  transformation  from  inertial  coordinates {£/},  to  body  coordinates  {£}, 
is  carried  out  as  follows,  and  is  shown  in  Figure  2.5. 

1.  The  inertial  coordinate  system  is  represented  by  the  vector  UV,  with  the 
components  x,  y,  and  z.  The  first  rotation  is  made  about  the  y  axis  through  an 
angle  0.  Now  the  vector  is  expressed  as  2V  with  the  components  X2,  j/2>  and  z2- 
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Figure  2.5:  Y-Z-X  Euler  Angle  Rotation  Sequence 


Since  the  rotation  was  about  the  y  axis,  the  y2  component  remains  unchanged. 
The  resulting  elemental  matrix  is: 


M(Q)  = 


cos  ©  0  —  sin  0 

0  1  0 

sin  0  0  cos  0 


(2.1) 


2.  Now  the  rotation  is  made  about  the  new  z  axis,  z2,  through  an  angle  This 
results  in  a  third  coordinate  system  with  the  vector  expressed  as  3V,  and  having 
components  x3,y3,  and  z 3.  This  rotation  does  not  change  the  z3  component. 
The  resulting  elemental  matrix  is: 


M(tf)  = 


cos  sin  0 
—  sin  ^  cos  ^  0 
0  0  1 


(2.2) 
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3.  Lastly,  the  rotation  about  the  x3  axis  through  an  angle  $  is  made  to  give  the 
vector  expressed  in  body  coordinates,  BV .  Now  the  resulting  elemental  matrix 


is: 


M(4>)  = 


1  0  0 

0  cos  $  sin  $ 

0  —  sin  $  cos  $ 


(2.3) 


When  the  matrices  are  multiplied  together  in  the  correct  sequence,  A/(4>)M(S')M(0), 
the  result  is  the  §R  direction  cosine  matrix,  expressed  in  terms  of  Euler  angles  as: 


cos'!*  cos©  sinty  —  cos'll  sin© 

—  cos$  sinty  cos©  +  sin4>  cos©  cos$cos^  cos$  sin'I' cos©  +  sin4>  cos© 
sin<I>  sin'I'  cos©  +  cos<I>  sin©  —  sin^cos'P  —  sin$  sin'P  sin©  +  cos<&  cos© 


(2.4) 


The  next  step  is  to  develop  the  kinematic  differential  equations  that  describe 
the  change  in  Euler  angles  with  time.  Following  the  method  used  in  [Ref.  7],  the 
matrix  of  differential  equations,  ft,  can  be  written  as  a  sum  of  individual  Euler  angle 


rates: 


n  =  M($) 


r  &*' 

'  0  " 

‘  0  1 

0 

+  M($)M(ip) 

0 

-© 
dt  u 

0 

L  dt*  J 

0 

(2.5) 


When  the  matrix  algebra  in  Equation  2.5  is  done,  the  resulting  kinematic  differential 


equations  for  p,  q ,  and  r  are  given  as: 


’  P 

1  sin  ^ 

0 

'  <D  ‘ 

Q 

= 

0  cos  $ 

cos  sin  $ 

0 

r 

0  —  sin  $ 

cos  $  cos  $ 

.  S'  . 

(2.6) 


The  matrix  on  the  right  hand  side  of  Equation  2.6  is  invertible  for  all  ±  and 
can  be  used  to  solve  for  the  Euler  angle  rates,  $,©  and 


'  S>  ' 

1  -  -  cos  $  tan  S'  sin  $  tan  S' 

’  P  " 

0 

— 

0  cc  s^sec'P  —  sin  $  sec  ^ 

9 

.  S'  . 

0  sin  $  cos  $ 

r 

(2.7) 


The  time  history  of  the  Euler  angles  can  be  obtained  by  integrating  Equation  2.7. 


4.  Derivation  of  the  Equations  of  Motion 

For  a  general  aircraft  model  with  six  degrees  of  freedom  the  derivation  of 
the  equations  of  motion  can  be  broken  into  two  parts.  The  first  part  is  the  motion 
of  an  arbitrary  rigid  body  in  free  space.  This  motion  depends  only  on  the  linear 
and  angular  momenta  of  the  rigid  body  which  can  be  divided  into  linear  and  angular 
equations.  The  second  part  is  an  examination  of  all  of  the  forces  acting  on  thai  rigid 
body.  These  forces  are  aerodynamic,  gravitational,  and  propulsive.  The  aerodynamic 
and  propulsive  forces  are  specific  to  the  aircraft  being  modeled  and  are  characterized 
by  the  stability  and  control  derivatives  described  later  in  this  thesis. 

a.  Linear  Equations 

The  linear  equations  are  developed  using  Newton’s  Law,  F  =  ma.  Be¬ 
cause  the  sensors  are  attached  to  the  body  of  the  aircraft,  the  equations  are  written 
in  the  {B}  coordinate  system.  Matrix  equations  avoid  the  repetition  of  writing  equa¬ 
tions  in  terms  of  x,  y,  and  z.  First  the  position  of  the  aircraft  center  of  gravity,  or 
c.g.,  (the  origin  of  {B})  is  determined  as  u  Pbo-  Next  Coriolis’  theorem  is  applied 
to  obtain  linear  velocities  for  the  aircraft.  Coriolis’  theorem  is  then  applied  a  second 
time  to  derive  the  equation  for  linear  accelerations.  First,  define: 

UVbo  =  U  Pbo-  (2.8) 

Both  sides  of  Equation  2.8  are  premultiplied  by  $R  to  get: 

§RuVbo  =  IRvPbo 
or 

bvbo  =  B  Pbo  (2.9) 
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Now  consider  Coriolis’  theorem: 


A  =  -^A  +  u  x  A,  (2.10) 

at 

where  A  and  A  A  use  the  notation  for  derivatives  previously  defined  in  Section  1  The 
term  u  x  A  represents  the  difference  between  the  relative  velocity  as  measured  from 
the  rotating  and  non-rotating  axes  [Ref.  8]. 

Equation  2.10  is  applied  to  BvB  in  Equation  2.9  to  get: 

dB 

BVBO=jj  x5  Ug,  (2.11) 

Newton’s  law  can  now  be  written  as: 

U  r.  _  ^  V  „ 

r  =  m  a 

=  m  vbo,  (2.12) 

where  u F  is  the  total  external  force  applied  to  the  aircraft  c.g.  Equation  2.12  is 
premultiplied  by  §R  to  obtain  the  result: 

bF  =  mBR  VvBO 

=  mBvBo •  (2.13) 

when  Equation  2.11  is  substituted  into  Equation  2.13,  the  final  result  for  BF  is: 

bF  =  m(-^  vb  +  B ub  xB  vb) 
at 

dB 

=  m  —  vB  +  mBuBxBvB.  (2.14) 

at 

b.  Angular  Equations 

The  angular  equations  are  derived  using  Euler’s  Law  for  preservation  of 
angular  momentum.  These  equations  are  derived  in  the  {£?}  coordinate  system  for 


the  c.g.  by  applying  Coriolis’  theorem  to  the  equation  for  Euler’s  Law: 


uLBo  =  v  N so  <  (2.15) 

where  u Lbo  is  the  angular  momentum  of  the  aircraft  and  u Nbo  is  the  total  external 
moment  applied  to  the  aircraft  c.g.  Then,  premultiplying  Equation  2.15  by  B  R  gives: 

BLbo  =  ZB"  Nbo,  (2.16) 

Using  Coriolis’  theorem  in  Equation  2.10,  bLBo  can  be  rewritten  as: 

bLbo  =  ~^B Lbo  +  bub  x  bLbo ,  (2-17) 

The  angular  momentum,  B Lbo,  is  defined  as  the  sum  of  the  product  of  the  inertia 
tensor,  Is,  and  the  body’s  angular  velocity,  BuB ,  and  the  product  of  the  inertia 
tensor  //*,  and  the  angular  velocity  of  any  rotating  parts  Bu )r,  or: 

bL  =  IB  Bug  +  Ir  B*r,  (2.18) 

where  Ir  and  blor  are  the  moment  of  inertia  and  the  angular  velocity  of  the  rotating 
part,  respectively.  Note  that  additional  rotating  parts  can  be  accounted  for  by  adding 
additional  terms  to  Equation  2.18.  With  a  single  propeller  the  equation  becomes: 

B L  =  IB  Bwb  +  Ip  {B wB  +  Bvp),  (2-19) 

where  Ip  and  Bup  are  the  moment  of  inertia  and  the  angular  velocity  of  the  propeller, 
respectively.  When  this  term  is  substituted  into  Equation  2.17,  the  result  is: 

B LBo  =  +  Ip{BwB  +  B<*>p))  +  bujb  x  (IbBvb  +  Ip{bwb  +  Bu?p)),  (2.20) 

at 

For  simplification,  define  the  total  inertia  tensor,  It  as: 

It  =  Ib  +  Ip  (2.21) 
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Collecting  terms,  Equation  2.20  becomes: 


B Lbo  =  —  (Itb&b  +  IpBup)  4  bwb  x  (ItB(*>b  +  IpBu}p),  (2.22) 
at 

Carrying  out  the  differentiation  in  Equation  2.22  yields: 

B Lbo  —  Jt~t:B^}b  4  Ip-rB^p  4  b^b  x  (Itb<*>b  +  IpBuJp).  (2.23) 
at  at 

Since  ^(bub)  =  bu>b  and  |(fluifi)  =  0  if  we  assume  a  constant  angular  velocity  for 
the  propeller,  Equation  2.23  can  be  simplified  to: 

B Lbo  —  ItBub  4  b^b  x  (ItBwb  +  IpBup)  (2.24) 

Now  the  result  in  Equation  2.24  can  be  substituted  into  Equation  2.16: 

B Nbo  =  ItBub  4  b&b  x  (Itbub  +  IpBup).  (2.25) 


The  term  IpBojp  can  be  disregarded  if  it  is  insignificant  compared  to  Ip  and  Bu>B 
[Ref.  9].  This  term  is  neglected  in  modeling  the  Bluebird  see  [Ref.  1].  For  the  case 
of  AROD  this  term  is  significant  and  is  not  negi  'ted. 


c.  State  Equations 


Now  that  the  kinematic  equations  of  motion  have  been  developed  in 
matrix  form,  these  equations  can  be  assembled  into  a  state-space  representation  of 
the  equations  of  motion.  First,  Equations  2.14  and  2.25  can  be  written  as: 


•  Bp  ' 

m  -fiBVB  4  m  ( bu)b  xb  vb ) 

.  BJV  . 

Itbu>b  4  b(jJb  x  (Itbvb  4  IpBuip) 

Equation  2.26  can  be  rearranged  to  yield: 


d 

m  bvb 

m  (-bub  xb  vb)  4 BF)  " 

dt 

Itbub 

—bu>b  X  (Itbub  4  IpBu>p)  4 BN) 

(2.26) 


(2.27) 
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d 

-bub  XB  vb  +  ~ 

It 

.  b^b  . 

-/f1  bub  X  ( Itbub  +  IpBujp)  +  /f1  BN 

The  terms  on  the  left  hand  side  of  Equation  2.27  can  be  normalized  by  multiplying 
by  jb  antj  /“*,  with  the  final  result: 


(2.28) 


d.  Forces  and  Moments 

Equation  2.28  gives  the  kinematic  equations  of  motion  for  a  rigid  body. 
The  next  step  is  to  examine  the  forces  B F  and  moments  B N  acting  on  the  rigid  body. 
These  forces  and  moments  are  due  to  gravity,  aerodynamics,  and  propulsion,  and  are 
written  as: 

T  Bp  1  r  Bp - _l  Bp _ i_  Bp _ 1 

(2.29) 


•  BF 

b  Fgrav  +  bFprop  +  bFAero 

bN 

bNprop  +  B  N aero 

Gravitational  Forces:  The  gravitational  forces  acting  on  the  air¬ 
craft,  B  Fgrav,  can  be  determined  by  rotating  u  Fgrav  with  the  appropriate  rotation 
matrix,  where: 


U  Fgrav  = 


0 
0 

mg  J 


(2.30) 


Then: 


fl  Fgrav  =  BRV Fgrav-  (2.31) 

Aerodynamic  Forces  and  Moments:  The  aerodynamic  force  and 
moment  terms  are  determined  by  using  first-order  Taylor  series  expansion  around  a 
given  nominal  operating  point.  This  operating  point  is  the  state  chosen  to  represent 
the  aircraft’s  flight  condition.  Each  term  in  the  series  is  a  partial  derivative  of  B F  or 
B N  with  respect  to  the  aerodynamic  variables,  jj,  a,  0,  p ,  <7,  r  [Ref.  7,  10): 


Faero  =  SFX'x'  +  6F±>x'  +  6F&  A  +  Fq. 


(2.32) 
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Similarly,  moment  terms  can  be  written  as: 


NAEro  =  6NX'X  +  6Ni.x'  +  6N±  A  -f  N0,  (2.33) 


where  x'  is  given  by: 


x  = 


_U 

U 

0 

a 

£t 

2  U 

3£. 

2  U 

rb 

L  2U  J 


(2.34) 


and  x'  is  given  as: 


x'  = 


0 

a 


(2.35) 


Notice  that  x'  contains  only  two  elements.  The  other  derivatives  are  negligible  and 
therefore  not  included.  Control  inputs  are  represented  by  the  vector  A: 


A  = 


Se 

Sr 

i  Sa  j 


(2.36) 


where  Se,  6r,  and  Sa  are  the  elevator,  rudder,  and  aileron  inputs,  respectively.  Equa¬ 
tions  2.32-2.36  can  now  be  combined  as  follows: 


w  p 
f  AERO 

w  Naero 


_^dC,dC.,dC  . 

=  +  7&x  +  +  Cf° 


dx' 


dA 


(2.37) 


where  q  =  | pV2,  S  =  diag{5,  S,  S,  Sb,  Sc ,  Sb},  and  C  is  the  matrix  of  non-dimensional 
stability  derivatives  differentiated  with  respect  to  the  terms  defined  in  Equation  2.34, 
2.35,  or  2.36.  is  defined  as: 


r  cLu 

Clp 

CLa 

Clp 

Cl, , 

cLr  1 

cYu 

Cy$ 

CYa 

cYp 

cYq 

cYt 

dC  a 

CDu 

Cdp 

Cd* 

Cdp 

Cnq 

Cdt 

dx ' 

Civ 

Cl, 

Cia 

Cb 

Cb 

Clr 

Cmu 

Cmp 

Cma 

cmp 

Cmq 

CmT 

.  Cnt, 

Cnp 

Cna 

Cnp 

Cnq 

Cnr 
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(2.38) 


|p  is  very  similar  to  |p,  except  that  only  the  a  and  0  terms  are  normally  significant, 
leaving  a  6  x  2  matrix  rather  than  a  square  matrix.  The  term  |£  is  defined  as: 


dC  a 
dA  ~ 


Cu. 

CLtr 

CLta 

CYt< 

°Y,r 

CYta 

CDit 

cd6t 

CDfa 

Cmic 

CmtT 

Cmta 

Cnit 

Cn(r 

Cp o  is  defined  to  be  the  vector  of  steady  state  coefficients: 


(2.39) 


CfO  — 


CDo 

Cyo 

Clo 

C/o 

Cmo 

CnO 


(2.40) 


representing  conditions  in  trimmed,  balanced  flight.  This  definition  is  similar  to  the 
definition  used  by  Roskam  [Ref.  9].  In  other  references,  the  term  Cfo  can  refer  to  the 
nominal  value  of  the  coefficient  at  a  =  0.  However,  in  the  Taylor  series  expansion 
it  is  more  natural  to  use  the  first  definition  of  Cfo’,  therefore,  it  will  be  used  in  the 
following  derivation  and  modeling.  The  stability  and  control  derivatives  are  usually 
computed  in  the  wind  axis  coordinate  system,  {W}.  The  transformation  from  {VT} 
to  {B}  is  performed  in  the  same  fashion  as  the  Euler  angle  transformations  mentioned 
earlier.  The  rotation  matrix,  fy/2,  is  a  function  of  a  and  0,  and  is  expressed  as: 


cos  a  cos  0  —  cos  a  sin  0  —  sin  a 
sin  0  cos  0  0 

sin  a  cos  0  —  sin  a  sin  0  cos  a 


(2.41) 


The  rotation  from  { VT}  to  {B}  is  made  by  premultiplying  the  force  or  moment  vector 
by  &R. 

Since  lift  and  drag  are  defined  as  positive  along  the  negative  zb  and  xb 
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axes,  we  define  FAEro  and  NAEro  as: 


‘  -D  ' 

'  l  " 

FAEro  = 

Y 

-L 

and  NAErq  = 

m 

n 

(2.42) 

The  negative  sign  on  D  and  L  can  be  moved  into  the  5  matrix  for  convenience,  so 
that  the  new  matrix  is: 


5  =  diag{— 5, 5,  -5,  56, 5c,  56} 


(2.43) 


In  order  to  write  Equation  2.37  in  state  space  form,  state  variables  must  be  defined. 
The  most  commonly  used  notation  to  use  for  the  state  vector  is  to  use: 


x  = 


u 

t> 

w 

p 

9 

r 


(2.44) 


However,  the  terms  x'  and  x'  in  Equations  2.32  and  2.33  cannot  be  used  directly  as 
states.  It  is  easy  to  define: 


where: 


and: 


M'  :  x  —*  x1 
M'  :  i  —>  x' 


juf,  A-  x  1  1  1  b  c 

M  =diag{  — ,— ,— , 


VT'  Vt'  Vt'  2Vt'  2Vt'  2Vt 


} 


M'  = 


0 


WI 


0  0  0  0 


0  0 


7Vl 


0  0  0 


(2.45) 


(2.46) 


(2.47) 


are  matrices  of  appropriate  dimensions.  The  complete  expression  for  B  FAEro  and 
BNAEro  can  now  be  written  as: 

&R  0 


bFAEro 

BNAEro 


=  qS 


0 


wR 


{CF0  +  ^M'x  +  §tM>x  +  ?£A}  (2.48) 


dx' 


dA 
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and  can  be  substituted  into  Equation  2.28. 

Propulsive  Forces  and  Moments:  The  propulsive  forces  and  mo¬ 
ments,  B  Fprqp  and  B  Nprop ,  are  computed  directly  in  the  body  coordinate  system 
{£?}  and  are  expressed  as: 

\TX  1 


B  F PROP  =  Ty  , 

.  Tz  . 


(2.49) 


B Nprop  =  |  Tm  j  ,  (2.50) 

where  the  T,'s  represent  the  forces  or  moments  due  to  thrust.  Computation  of  propul¬ 
sive  forces  and  moments  depends  on  each  particular  engine  installation,  and  must  be 
determined  for  the  individual  aircraft  modeled.  For  the  AROD,  the  thrust  is  aligned 


in  the  XB  direction  and  located  at  the  c.g.  yielding: 

Tx 

B  Fprop  =  0  , 

0 


B  Nprop  =  0  , 

.  0  . 

Equations  2.31,  2.51,  and  2.52  can  now  be  substituted  into  Equation  2.28: 
d  r  Bvbo  1  r  -BuBx  0  If  bvbo 


(2.51) 


(2.52) 


dt  b 


-bIt'{B*b*  ( bItbub  +  IpBuP ))  I  I  bu}B 


4  0  I  f  BF 

m 

0  s/t1  bn 


,(2.53) 


where: 


0 

0  &R 


BF  j  bFqrav  ,  bFprop  lr, 

M=U  0  ]  +  l»JwjM' 

•  ?-S{  Cro  +  SM'.  +  +  J£A  }  )  } 


(2.84) 


e.  Complete  Equations  of  Motion 


In  order  to  write  Equation  2.28  in  state  space  form,  the  terms  associated 
with  x'  must  be  collected  and  moved  to  the  left  hand  side,  along  with  the  other  time 
derivative  terms,  bvbo  and  bujb •  Let: 

«t = [  V  /fi] = [  s  4']'  (2-55) 


then  the  complete  non-linear  equations  of  motion  for  any  aircraft  can  be  expressed 
in  state  space  form  as  follows  [Ref.  11]: 


and: 

A  =  5(A)%j,  (2.58) 


where: 

A  =  0  (2.59) 

# 

1  —  cos  $  tan  sin  $  tan 

5(A)  =  0  cos  $  sec  'P  —  sin  $  sec  $  (2.60) 

0  sin  $  cos  $ 

and: 

X  =  (2.61) 

P  is  the  position  vector  of  the  aircraft,  and  5(A)  is  the  matrix  of  kinematic  differential 
equations  based  on  Euler  angles. 
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III.  COMPUTER  MODELING 


Now  that  the  full  non-linear  equations  of  motion  have  been  developed,  the  next 
step  is  to  model  the  aircraft  on  a  computer.  Notice  that  Equations  2.56,  2.57,  and 
2.58  are  in  a  generic  format.  That  is,  they  could  be  used  to  represent  the  AROD 
or  the  Bluebird  or  any  propeller  driven  aircraft  provided  the  correct  values  are  used 
for  the  stability  and  control  derivatives,  |p,  |p,  and  |^,  as  well  as  the  forces  and 
moments  due  to  thrust,  B Fprop  and  B Nprop-  For  this  reason,  it  is  convenient  to 
create  a  model  which  accepts  these  values  from  a  generic  input  file.  This  allows  the 
same  model  to  be  used  for  different  aircraft  by  simply  changing  the  input  data  to 
correspond  to  the  new  aircraft.  Validation  of  the  model  can  then  be  accomplished 
by  entering  the  appropriate  data  for  a  well  known  aircraft,  such  as  a  Cessna,  and 
comparing  the  results  of  the  model  to  existing  data. 

For  this  report  it  was  desirable  to  begin  with  an  existing  computer  model  that 
had  already  been  tested  in  hardware-in-the-loop  simulation  so  that  the  results  could 
be  compared.  The  model  and  controller  chosen  for  the  AROD  were  developed  and 
tested  by  N.  Sivashankar.  The  System Buildmodel  he  developed  is  explained  here 
since  he  chose  not  to  present  it  in  his  report  [Ref.  3].  For  his  hardware-in-the-loop 
test,  he  developed  C  code  for  the  controller  to  run  on  a  386  PC  and  developed  a 
model  of  AROD  in  VisSim  to  run  on  a  486  PC.  His  hardware-in-the-loop  setup  is 
outlined  later  in  Chapter  VI  Section  A  and  in  his  report. 

The  SlMULINK  model  developed  in  this  section  was  not  used  to  develop  a  con¬ 
troller  and  is  presented  here  as  an  example  of  how  to  implement  the  equations  of 
motion  in  a  SlMULINK  block  diagram.  For  an  example  of  how  to  implement  these 
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equations  in  SlMULINK  for  the  Bluebird  see  [Ref.  1]. 

A.  BASIC  NONLINEAR  MODEL 

The  basic  nonlinear  model  is  essentially  the  same  for  both  SlMULINK  and  Sys- 
temBuild.  The  state  derivative  equations,  Equation  2.56,  are  implemented  and  fed 
into  an  integrator  block  which  feeds  back  into  the  derivative  equations. 

1.  Basic  SlMULINK  Model 

The  SlMULINK  model  is  shown  in  Figure  3.1,  and  is  simply  a  block  repre¬ 
senting  the  state  derivative  equations,  Equation  2.56,  and  an  integrator  block  in  a 
feedback  loop.  The  SlMULINK  implementation  of  the  equations  of  motion  is  simpli¬ 
fied  by  using  a  MaTLAB  function  block.  The  program  listing  for  this  function  block 
is  given  in  Appendix  A.  Notice  that  the  stability  and  control  derivatives  as  well  as 
the  forces  and  moments  due  to  thrust  are  found  in  a  separate  MaTLAB  script  file. 
Appendix  A  shows  this  file  with  the  values  for  AROD  in  a  hover.  This  MaTLAB 
function  has  deliberately  not  been  optimized  to  clearly  show  how  the  equations  of 
motion  are  implemented.  The  forces  and  moments  due  to  thrust  were  measured  by 

B.  Stoney,  [Ref.  12],  and  are  given  by: 

Tprop  =  0.0297  Srpm  -  104.7,  (3.1) 

and: 

Iprop  =  -0.0542  Tprop  -  0.9138,  (3.2) 

2.  Basic  SystemBuild  Model 

The  state  derivative  equations  could  be  implemented  on  SystemBuild  in  a 
similar  manner  using  an  user  code  block.  This  involves  writing  a  C  or  FORTRAN 
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Arod  Non-Linear  Model 


Figure  3.1:  SiMUUNK  Block  Diagram  of  the  Equations  Of  Motion 

function  which  is  then  linked  into  the  SystemBuild  diagram.  The  Bluebird  model 
used  for  hardware-in-the-loop  testing  was  developed  in  this  way  by  J.  Byerly.  For  a 
detailed  explanation  of  how  to  implement  the  nonlinear  model  with  user  code  blocks 
see  his  report  [Ref.  13]. 

The  nonlinear  SystemBuild  model  of  AROD  is  shown  in  Appendix  B.  The 
highest  level  consists  of  an  input  block  for  the  constants,  a  SuperBlock  for  the  aircraft 
kinematics,  and  a  SuperBlock  for  all  of  the  integrators.  The  kinematics  SuperBlock  is 
made  up  of  three  SuperBlocks  representing  the  angular  velocity  equations,  the  linear 
velocity  equations,  and  the  Euler  angular  rates.  The  ’L_dot_eq’  SuperBlock  imple¬ 
ments  Equation  2.58  directly.  The  ’lin.velocityjeq’  SuperBlock  adds  Equation  2.31, 
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Equation  2.51,  and  the  first  term  of  Equation  2.53.  The  result  is  the  linear  portion 
(the  jtBVBO  portion)  of  Equation  2.56.  The  ’ang_velocity_eq’  SuperBlock  implements 
the  angular  portion  (the  jBojb  portion)  of  Equation  2.56.  These  values  are  then  fed 
into  an  integrator  block  tc  determine  the  states. 

B.  DISCRETE  MODEL 

Since  the  AC100  Model  C30  can  not  automatically  generate  code  for  a  continu¬ 
ous  system,  iue  model  must  be  discretized.  The  goal  is  to  simulate  a  continuous  time 
system  using  a  discrete  time  system.  SlMULINK  and  SystemBuild  do  this  by  using  a 
very  small  time  step  size  with  a  continuous  type  integration  algorithm.  The  continu¬ 
ous  mode!  can  be  discretized  in  SystemBuild  with  the  ’Transform  SuperBlock’  option 
under  the  ’Build’  menu.  Simply  choose  a  small  step  time  and  the  SuperBlocks  are 
automatically  transformed.  The  only  difference  is  that  all  integrators  will  be  replaced 
by  ’discrete’  integrators  as  shown  in  Figure  3.2,  where  T  is  the  step  time  chosen  for 
the  discrete  system. 

Figure  3.2:  Transformation  of  an  Integrator  from  Continuous  Time  to 
Discrete  Time 

The  step  time  must  be  evaluated  with  the  model  to  determine  the  optimum 
step  time.  If  the  step  time  is  too  large  the  discrete  system  will  not  be  an  accurate 


model.  If  the  step  time  is  too  small  the  computation  time  necessary  may  slow  down 
the  discrete  system  to  the  point  where  it  becomes  unstable. 

C.  TESTING  THE  MODEL 

The  performance  of  the  aircraft  model  must  be  verified.  This  is  usually  ac¬ 
complished  by  replacing  the  stability  and  control  values  with  those  of  a  well  known 
aircraft  such  as  a  Cessna.  The  nonlinear  model  can  then  be  trimmed  at  a  given 
flight  condition  and  the  eigen  values  of  the  resulting  linear  model  can  be  compared 
to  existing  data. 

1.  Testing  the  Simulink  Model 

The  SIMULINK  model  of  AROD  presented  here  was  trimmed  for  the  hover 
condition  and  linearized.  The  resulting  state-space  matrices  were  identical  to  the 
state-space  matrices  determined  by  D.  Kuechenmeister  [Ref.  2].  Since  this  model 
was  not  used  to  develop  a  controller,  no  further  testing  was  completed. 

2.  Testing  the  SystemBuild  Model 

The  SystemBuild  model  of  AROD  developed  by  N.  Sivashankar  also  pro¬ 
duced  the  same  state-space  matrices  when  trimmed  and  linearized  for  hovered  flight. 
Refer  to  his  report  for  more  details  on  the  testing  of  his  model  [Ref.  3]. 
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IV.  DESIGN  AND  SOFTWARE  TESTING  OF 

THE  CONTROLLER 


Now  that  a  valid  linear  model  has  been  developed,  the  controller  can  be  designed. 
First,  the  designer  determines  which  states  or  outputs  are  available  for  feedback  and 
the  control  inputs  to  be  used  by  the  controller.  For  the  AROD,  the  following  states 
are  measured: 


x  = 


P 

<7 

r 

e 

0 


(4.1) 


The  inputs  are  elevator,  rudder,  aileron,  and  rpm  (revolutions  per  minute  of  the 
propeller): 


&  Input  — 


6c 

6r 

6a 


Jrpm 


(4.2) 


Hoo  synthesis  was  used  to  design  the  state  feedback  controller.  It  is  outlined  in  the 
next  section. 


A.  HooSYNTHESIS  MODEL 

Consider  Figure  4.1.  Here  w  represents  exogeneous  inputs,  z  represents  regu¬ 
lated  outputs,  P  represents  the  plant  model,  y  represents  the  actual  plant  output, 
and  uc  is  the  control  input  created  by  the  controller.  Using  the  notation  in  [Ref.  14], 
suppose  the  plant  is  partitioned  as: 


P  = 


P 11  P\2 

P 21  P22 


(4.3) 
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Figure  4.1:  Hoc  Synthesis  Model 


so  that: 


z  =  Pn  w  +  Puu  y  —  P21  w  +  P22 


Then  u  and  y  can  be  eliminated  using  u  =  Ky,  to  obtain: 

2  =  [Pn  +  P12  K  (I  —  P22  K r1  Pn\  w, 


This  is  normally  denoted  by: 


z  =  Fl(P,K)w 


The  Hoo  optimization  problem  is  then: 


Find  K  which  minimizes  ||Fi(F,  /0||oo 


For  the  AROD,  the  input  u>i  shown  in  Figure  4.1  is  defined  as: 

roll  rate  command 
=  pitch  command 
yaw  command 


and  the  input  W2  is: 


The  control  commands  are: 


The  signals  xx  and  x^  are: 


u>2  =  rpm  input 


elevator 
uc  =  rudder 
aileron 


P 

x\  =  0 

* 


(4.10) 


(4.11) 


The  designer  changes  the  cost  function  weights  Wj,  W^,  and  W3  to  obtain  the  desired 
bandwidth  in  the  command  and  control  loops.  [Ref.  15] 

B.  DISCRETE  CONTROLLER 


The  controller  obtained  using  Ho,  synthesis  has  the  following  state-space  repre¬ 


sentation: 


c  .  r  ic  =  Bc{yx  -  yc ) 

'  x  u  =  Cc  xc  +  Dc  yj 


(4.12) 


Since  C  will  be  implemented  on  the  digital  computer  it  must  be  discretized  first: 


n  .  j  {xc)k+ 1  —  AT  Bc  (j/i  J/c)x 

D  uk  =  Cc  xCK  +  Dc  y2K 

where  AT  is  the  sampling  period  of  the  discrete  time  system. 


1.  SystemBuild  Discrete  Controller 


(4.13) 


The  SystemBuild  implementation  of  a  discrete  controller  uses  a  state-space 
block  with  the  appropriate  values  as  a  matrix  gain.  The  discrete  controller  for  AROD 


is  shown  in  Appendix  B  Figure  B.4.  Notice  that  for  this  implementation  AT  has  been 
multiplied  into  the  B  matrix  instead  of  the  control  gain  matrix. 

C.  CLOSED-LOOP  SOFTWARE  TESTING 

The  procedure  for  closed-loop  testing  of  the  controller  is  basically  the  same  for 
both  continuous  and  discrete  time  systems.  The  model  and  controller  are  connected 
as  shown  in  Figure  4.2.  Note  that  the  discrete  time  controller  could  be  tested  with 
the  continuous  time  model  if  the  outputs  of  the  discrete  controller  are  routed  through 
a  zero-order  hold  before  being  input  to  the  continuous  model.  This  step  is  done  auto¬ 
matically  by  SystemBuild  when  discrete  and  continuous  SuperBlocks  are  connected 
within  the  same  block  diagram. 

1.  SystemBuild  Testing 

SystemBuild  testing  can  be  accomplished  in  several  ways.  All  of  these 
methods  require  the  user  to  define  a  time  vector.  For  a  40  Hertz  controller  the 
time  vector  might  be: 

t  =  0  :  0.025  :  20;  (4.14) 

Which  produces  a  vector  of  801  elements,  starting  at  zero,  spaced  at  0.025  seconds, 
and  ending  after  20  seconds.  The  user  can  define  an  input  vector  in  MATRIX* 
or  connect  signal  generator  blocks  inside  the  model.  The  user  then  selects  ’Analyze 
SuperBlock’  from  the  ’Build’  menu  and  enters  the  appropriate  values.  Typing  ’sim’  at 
the  MATRIX*  prompt  will  begin  the  test  and  create  a  matrix  of  output  values.  The 
output  matrix  can  be  broken  into  vectors  and  observed  using  the  ’plot’  command. 
The  results  of  this  test  for  the  AROD  are  presented  in  [Ref.  3]. 
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Figure  4.2:  Closed-Loop  Block  Diagram 

2.  AC100  Model  C30  Testing 

The  discrete  model  can  be  tested  on  the  AC  100  Model  C30  by  following 
the  procedures  outlined  later  in  Chapter  VI  Section  B  without  connecting  any  of  the 
hardware.  The  closed-loop  connections  are  left  in  the  model  and  the  desired  outputs 
are  selected  for  the  Interactive  Animation  display.  The  test  results  will  be  identical 
to  those  found  above  since  the  C30  processor  is  using  the  exact  same  closed-loop 
system  as  SystemBuild. 
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V.  MODELING  ACTUATORS  AND  SENSORS 


For  both  the  AROD  and  the  Bluebird,  all  of  the  control  surfaces  are  actuated  by 
Futaba  FP-S34  servo  motors.  These  actuators  where  originally  modeled  by  Sandia 
Labs  as  a  second  order  system  with  (  =  0.6  and  un  =  20  radians. 

ujI 

^  S2  +  2  C  S  +  U>2  ’ 

This  section  examines  the  development  of  an  accurate  model  for  these  actuators. 

A.  ACTUATOR  STEP  RESPONSE 


The  step  response  of  a  system  can  be  used  to  determine  its  transfer  function 
[Ref.  16].  An  example  step  response  is  shown  in  Figure  5.1.  This  response  is  typical 
for  an  underdamped  second  order  system.  To  determine  the  transfer  function,  it  is 
necessary  to  determine  the  values  for  Mp  and  tT. 

The  measured  step  response  for  the  Futaba  servos  is  shown  in  Figure  5.2  with 
the  step  response  for  the  transfer  function  given  in  Equation  5.1.  This  step  response 
was  measured  using  the  data  acquisition  feature  of  the  AC100  Model  C30  and  the 
test  setup  outlined  in  the  next  chapter. 

The  values  for  Mp  and  tr  were  measured  as: 

Mp  =  0.1197  tT  =  .059  ,  (5.2) 

With  these  values  a  second  order  transfer  function  can  be  created  by  calculating  the 
natural  frequency  uin  and  the  damping  ratio  C  using  the  following  formulae: 

c  ln(Mp) 
yJln(Mp)2  -f  7T2 


(5.3) 


Figure  5.1:  Typical  Step  Response  of  an  Underdamped  System 


and: 


These  calculations  resulted  in: 


_7i 


(5.4) 


=  19.94  C  =  .559  ,  (5.5) 

Since  the  step  response  did  not  match  well  with  the  step  response  of  the  calculated 
transfer  function,  a  limited  frequency  response  of  the  actuators  was  measured. 

B.  ACTUATOR  FREQUENCY  RESPONSE 

The  actuators  were  given  a  sinusoidal  command  input  and  the  response  was 
measured  for  frequencies  of  1,  2,  3,  and  4  Hertz.  This  procedure  could  have  been 
duplicated  for  many  more  frequencies  and  the  result  would  be  a  complete  frequency 
response  for  the  actuators.  Figure  5.3  shows  the  frequency  response  at  3  Hertz.  Each 
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Figure  5.2:  Step  Response  of  Actuator  and  Second  Order  Model 

pole  in  a  system  will  result  in  a  total  of  90  degrees  of  phase  shift  in  the  frequency 
response  and  half,  or  45  degrees,  of  this  shift  occurs  at  the  natural  frequency  [Ref. 
16].  Since  the  measured  phase  difference  was  approximately  180  degrees  at  3  Hertz, 
the  servo  motors  are  more  accurately  modeled  as  fourth  order  systems. 

One  possible  fourth  order  model  was  determined  and  is  given  in  Figure  5.4. 
Figure  5.5  shows  the  step  response  of  the  actuator  and  the  fourth  order  model  step 
response. 

C.  ACTUATOR  SENSORS 

Since  the  hardware-in-the-loop  test  will  not  cause  the  aircraft  to  move,  aircraft 
sensors  such  as  Inertial  Measuring  Units  and  Air  Data  Sensors  can  not  be  used. 


38 


Tim*  (MOMidi) 


Figure  5.3:  Frequency  Response  of  an  Actuator  at  3  Hertz 


Figure  5.4:  Fourth  Order  Actuator  Model 

Therefore  the  actuator  positions  must  be  determined.  This  is  accomplished  using  an 
angular  position  sensor.  The  measured  vane  positions  can  then  be  used  to  determine 
the  states  of  the  aircraft  so  that  an  hardware-in-the-loop  test  can  be  preformed. 

The  Futaba  servos  used  do  not  include  a  separate  position  sensor.  There  is  an 
internal  control  circuit  which  determines  which  direction  and  how  far  to  move  the 
servo  based  on  the  input  signal.  This  input  signal  is  a  Pulse  Width  Modulated,  or 
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Figure  5.5:  Step  K  <ponse  of  Actuator  and  Fourth  Order  Model 

PWM,  pulse.  The  length  of  the  pulse  determines  how  far  the  servo  is  to  turn.  The 
previous  hardware-in-the-loop  test  defined  the  throw  of  these  actuators  as  being  from 
0  to  200  degrees  with  the  center  position  at  100  degrees.  For  this  report  the  center 
position  is  defined  as  0  degrees  with  full  throw  being  plus  or  minus  100  degrees.  A 
pulse  width  of  approximately  0.3  milli-seconds  corresponds  to  —100  degrees  while 
a  pulse  width  of  approximately  2.4  milli-seconds  corresponds  to  +100  degrees.  The 
internal  control  circuit  includes  a  small  potentiometer  in  a  feedback  loop  to  control  the 
motor.  The  servos  were  modified  to  include  wires  connected  to  the  center  and  ground 
leads  of  this  potentiometer  as  shown  in  Figure  5.6.  The  voltage  across  these  two  wires 
was  then  measured  and  divided  by  5  volts,  (the  supply  voltage),  to  determine  the 
position  as  a  ratio  of  the  total  allowable  motion. 
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Figure  5.6:  Actuator  Sensors 

This  sensor  design  depends  on  a  constant  5  volts  being  applied  to  the  positive 
end  of  the  potentiometer.  Since  the  same  voltage  also  supplies  power  to  the  servo 
motor,  this  voltage  actually  changes  slightly  while  the  motor  is  turning.  The  servo 
motors  draw  approximately  8  milli-amperes  of  current  when  they  are  not  moving  and 
up  to  200  milli-amperes  when  they  are  moving.  The  increased  current  draw  during 
motion  causes  a  drop  in  the  supply  voltage.  Since  the  measured  voltage  is  always 
divided  by  5  volts  the  result  is  a  noisy  sensor  position.  This  noise  was  measured  as 
approximately  one  half  of  one  degree  in  each  of  the  four  vanes.  Since  these  sensed 
positions  are  used  to  determine  the  aircraft  states,  noise  enters  all  of  the  states.  The 
most  pronounced  effect  of  this  noise  shows  up  in  the  roll-rate  p  because  all  of  the 
vanes  add  together  to  determine  the  aileron  command.  A  0.5  deg  change  in  all  of  the 
vanes  from  one  measurement  to  the  next  is  equivalent  to  an  aileron  control  surface 
movement  of  80  degrees  per  second. 

To  reduce  this  noise  an  additional  wire  was  added  so  that  the  positive  voltage 
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on  the  potentiometer  could  be  measured  at  the  same  time  as  the  center  voltage. 
Figure  5.7  shows  the  new  sensor  wiring. 


Servo  Motor  High  Tap 


Figure  5.7:  Modified  Actuator  Sensors 


Now  the  ratio  of  the  voltage  measured  from  the  ground  to  the  center  tap,  over 
the  voltage  from  the  ground  to  the  high  tap  gives  the  position  as  a  percentage  of 
total  motion. 

Center  Tap  _  %  motjon  (5.6) 

VHighTap 

The  result  of  the  new  sensor  design  was  an  order  of  magnitude  reduction  in  the  sensor 
noise.  Figure  5.8  shows  the  measured  response  of  an  actuator  to  a  2  Hertz  sine  wave 
input.  The  two  wire  response  was  measured  prior  to  adding  the  additional  wire  to 
the  sensor.  The  responses  have  been  time  shifted  for  clarity. 

D.  UNDER-SAMPLING 

When  continuous  time  signals  are  sampled  at  less  than  the  Nvquist  frequency 
and  then  reconstructed,  the  resulting  waveform  will  have  low  frequency  components. 
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Figure  5.8:  Noise  Comparison  of  Actuator  Sensors 


This  effect  is  known  as  under-sampling  [Ref.  17]. 

A  common  example  of  under-sampling  can  be  seen  on  television.  The  video 
camera  essentially  takes  samples  of  the  continuous  time  world  and  presents  them  in 
a  discrete  fashion.  The  human  eye  captures  these  discrete  pictures  and  filters  them 
so  that  the  mind  perceives  continuous  motion.  When  the  video  camera  samples  a 
rotating  object  such  as  a  wagon  wheel  at  a  frequency  less  than  the  Nyquist  rate  for 
the  rotation  speed,  the  wheel  may  appear  to  turn  backwards.  Figure  5.9  shows  how  a 
37  Hertz  sine  wave,  sampled  at  20  Hertz,  appears  to  be  a  3  Hertz  sine  wave.  The  solid 
line  is  the  continuous  time  sine  wave,  the  asterisk  symbols  are  the  20  Hertz  samples, 
and  the  dashed  line  is  the  continuous  time  estimate  of  the  samples.  Notice  that  the 
reconstructed  wave  starts  out  negative.  If  this  were  a  mathematical  representation  of 
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the  wagon  wheel,  it  would  appear  to  turn  backwards.  The  effects  of  under-sampling 
were  eliminated  in  the  AROD  by  the  technique  used  to  reduce  aliasing  which  is 
discussed  next. 


Figure  5.9:  Under-Sampling  of  a  Continuous  Time  Signal 

E.  ANTI-ALIASING 

Sampling  a  continuous  time  signal  results  in  an  infinite  train  of  ’copies’  of  the 
sampled  signal  repeating  at  integer  multiples  of  the  sampling  frequency  [Ref.  17]. 
Aliasing  occurs  when  the  sampling  frequency  is  such  that  these  ’copies’  overlap.  Fig¬ 
ure  5.10  shows  the  frequency  response  of  an  example  signal,  the  sampled  frequency 
response  when  sampled  at  50  Hertz,  and  the  sampled  frequency  response  when  sam¬ 
pled  at  16  Hertz.  The  area  between  the  triangles  in  the  third  response  is  called 
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aliasing. 


Frequency 


Figure  5.10:  Example  of  a  Continuous  Time  Signal  and  Aliasing 

The  effects  of  aliasing  were  reduced  in  the  AROD  hardware-in-the-loop  test  by 
adding  an  anti-aliasing  filter.  The  sensor  voltages  were  sampled  at  1000  Hertz.  The 
ratio  of  the  two  voltages  was  then  fed  into  a  third  order  low-pass  Butterworth  filter 
with  a  cut-off  frequency  of  10  Hertz.  The  output  of  this  filter  is  then  sampled  at  40 
Hertz  eliminating  aliasing  of  any  noise  in  the  frequency  range  of  interest.  Appendix  B 
includes  the  SystemBuild  block  diagrams  for  the  anti-aliasing  filters.  The  discrete 
low-pass  filter  was  implemented  using  the  ’FUR’  command  in  MATRIX*.  The  result¬ 
ing  state-space  matrix  was  then  put  into  the  SystemBuild  block  diagram.  A  separate 
filter  was  necessary  for  each  of  the  four  vanes.  The  state-space  representation  of  the 
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filter  is  given  by: 


Af  Bp 

n  n 


(5.7) 


For  the  AROD,  the  frequency  response  of  interest  is  from  0  to  3  Hertz  (approx¬ 
imately  20  radians).  The  noise  is  estimated  to  have  major  components  at  40  Hertz 
and  harmonics  of  40  since  the  PWM  frequency  is  40  Hertz.  By  sampling  at  1000 
Hertz,  we  are  assuming  that  the  noise  level  is  insignificant  for  frequencies  above  500 
Hertz.  The  10  Hertz  cutoff  frequency  on  the  filter  is  designed  to  eliminate  the  noise 
at,  and  above  40  Hertz. 
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VI.  HARDWARE-IN-THE-LOOP  TESTING 


The  most  critical  phase  of  testing  is  the  hardware-in-the-loop  test  of  a  con¬ 
troller.  This  is  usually  the  final  validation  of  a  controller  prior  to  an  actual  flight 
test.  Typically  this  involves  the  actual  control  computer,  actuators  and  some  or  all 
of  the  actual  sensors.  In  the  case  of  the  AROB,  the  only  sensors  that  can  be  used 
for  this  test  are  the  servo-motor  position  sensors.  Since  no  motion  is  involved,  the 
IMU,  GPS,  and  Air  Data  sensors  would  not  produce  usable  data  and  therefore  these 
sensors  must  be  modeled  along  with  the  aircraft. 

The  controller  is  typically  implemented  on  a  microprocessor  capable  of  interfac¬ 
ing  with  the  required  hardware.  In  this  case  a  486  PC  type  computer  is  the  intended 
control  computer.  For  the  first  hardware-in-tbe-loop  test,  the  AC100  Model  C30  will 
serve  as  the  control  computer  and  as  the  plant  model  computer.  Later,  the  con¬ 
troller  will  be  separated  and  implemented  on  the  486  PC.  Before  discussing  the  new 
hardware-in-the-loop  test  setup,  the  previous  test  setup  is  presented  for  comparison. 

A.  PREVIOUS  TEST  SETUP 

Before  automation  of  hardware-in-the-loop  testing,  the  aerospace  controls  en¬ 
gineer  had  to  rely  on  computer  scientists  or  know  how  to  program  in  a  high  level 
language.  For  his  hardware-in-the-loop  test,  N.  Sivashankar  wrote  C  code  for  the 
controller  and  for  all  of  the  necessary  I/O  drivers.  His  setup  is  presented  in  his  re¬ 
port,  [Ref.  3],  and  briefly  outlined  here.  The  complete  setup  is  shown  in  Figure  6.1. 
The  386  PC  runs  the  controller  and  outputs  PWM  signals  to  the  vanes.  The  486  PC 


47 


senses  the  vane  positions  and  computes  the  new  states.  The  486  PC  then  sends  out 
analog  signals  to  simulate  the  angular  rate  sensors  and  the  euler  angle  sensors. 


Figure  6.1:  Previous  Setup  for  Hardware-In-The-Loop  Simulation 

The  basic  configuration  of  the  386  PC  is  shown  in  Figure  6.2.  The  386  PC 
reads  the  analog  inputs  and  converts  the  measured  values  to  the  correct  units  for 
the  controller.  The  new  control  commands  are  then  computed  and  sent  out  by  the 
counter/timer  board  as  PWM  signals. 


Figure  6.2:  Configuration  of  the  Data  Acquisition  Cards  on  the  386  PC 


The  configuration  of  the  486  PC  is  shown  in  Figure  6.3.  The  vane  sensor  voltages 
are  rei/i  by  VisSim  and  then  used  to  calculate  the  new  aircraft  states.  The  angular 
rates  p,  q,  and  r  and  the  angles  6  and  -0  are  then  sent  out  as  analog  signals  to  the 
386  PC  simulating  the  angular  sensors. 

The  most  significant  problem  of  this  hardware-in-the-loop  test  setup  was  the 
speed  of  the  AROD  model.  The  VisSim  model  of  AROD  could  not  be  run  in  real  time, 
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Figure  6.3:  Configuration  of  the  Data  Acquisition  Cards  on  the  486  PC 

thus  the  controller  had  to  be  artificially  slowed  to  4  Hertz.  The  control  algorithm 
was  implemented  in  C-code  as  a  function  call  which  was  driven  by  an  interrupt.  By 
design,  this  interrupt  should  have  been  at  a  rate  of  40  Hertz.  Since  the  VisSim  model 
could  not  produce  updated  states  at  this  rate,  the  interrupt  was  slowed  to  4  Hertz. 
In  this  way,  the  controller  performed  as  if  it  were  running  at  40  Hertz  while  actually 
running  at  4  Hertz.  For  more  details  refer  to  [Ref.  3]. 

B.  AC100  GRAPHICAL  USER  INTERFACE 

The  new  hardware-in-the-loop  test  setup  utilizes  Integrated  Systems,  Incorpo- 
r-.ed’s  AC100  Model  C30.  The  AC100  Graphical  User  Interface,  or  GUI,  is  the 
workstation  users  link  to  all  of  the  necessary  software  tools  for  modeling  and  testing. 
Prior  to  using  the  GUI,  the  user  must  ’source’  the  ’aclOOsetup’  file.  This  is  done  by 
typing: 

’source  $ISI/ AC  1 00/bin/ acl  OOsetup  .sh  ’ 

at  the  unix  prompt.  This  line  can  also  be  included  in  the  ’.login’  file  so  that  the 
’aclOOsetup.sh’  file  is  automatically  run  each  time  the  user  logs  in  to  the  workstation. 
This  section  assumes  that  the  user  has  manually  entered  MATRIX*  previously  and 
is  using  the  GUI  for  the  first  time  now  that  the  controller  and  model  are  complete. 
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The  AC100  manuals  refer  to  a  model  and  controller  as  a  project,  [Ref.  18, 19,  20] 
with  the  project  name  being  the  name  of  the  highest  level  SuperBlock  in  the  diagram. 
There  are  standard  files  which  must  be  present  in  the  local  directory  for  each  project 
which  have  common  names  and  the  AC100  uses  file  extensions  to  separate  files  within 
a  project.  It  is  required  to  use  a  separate  directory  for  each  project  to  avoid  using 
the  project  files  from  one  project  with  the  standard  files  of  another  project. 

The  first  of  these  standard  files  is  the  animation  configuration  file,  ( animat  ion.  cfg). 
Each  project  will  have  a  slightly  different  ’animation. cfg’  file,  but  it  must  have  that 
name.  To  create  this  file,  type  ’makeproject’  at  the  unix  prompt.  The  program  will 
assume  that  the  project  name  is  the  same  as  the  directory  name.  If  this  is  true,  the 
user  may  accept  all  of  the  default  settings  by  hitting  ’enter’  at  each  prompt. 

The  next  standard  file  is  the  ’target_config.cfg’  file.  To  create  this  file  the  user 
types  ’retarget’  at  the  Unix  prompt.  The  user  will  be  asked  for  the  ’aclOOhostname’ 
which  is  either  ’AC100’  or  ’america’.  All  of  the  remaining  defaults  should  be  selected. 
These  files  are  only  created  once  for  each  project.  Now  that  these  basic  files  have 
been  set  up,  the  user  types  ’aclOO’  at  the  unix  prompt  to  start  the  GUI.  The  GUI 
is  used  with  the  mouse  and  a  single  left  mouse  button  click  will  activate  the  selected 
function.  Figure  6.4  shows  the  AC100  GUI. 

The  basic  project  file  containing  all  of  the  required  information  about  the  model 
and  controller  including  the  input  and  output  names  is  the  real-time  file.  This  file  is 
created  by  selecting  ’Generate  Real-Time  Code’  from  the  SystemBuild  ’Build’  menu 
and  selecting  the  top  level  SuperBlock  from  the  list.  The  file  name  can  be  specified 
and  defaults  to  the  name  of  the  SuperBlock  selected  with  the  ’.rtf’  extension.  The 
user  can  then  exit  MATRIX*  and  select  ’Autocode’. 
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tj  i  _  j.  _  Current  tnimacm  canfigurationii  ei_t*t4_hw 

*  La*t  action  was  LOAD  ANIMATION  CONFIG,  click  on  a  button  to  take  specified  action 


Figure  6.4:  AC  100  Graphical  User  Interface 

The  next  step  is  to  build  the  Interactive  Animation,  or  IA,  display  to  be  used 
during  the  hardware-in-the-loop  test.  The  user  will  first  need  to  determine  which 
outputs  to  display  and  which  inputs  are  desired  for  interaction  with  the  running 
model  and  controller.  The  user  may  need  to  add  inputs  and  outputs  to  get  the 
desired  results. 

1.  Interactive  Animation 

The  user  clicks  on  the  ’Interactive  Animation  Builder’  block  to  design  the 
interface  screen  for  working  with  the  C30.  The  main  I A  picture  for  the  AROD 
hardware-in-the-loop  test  is  shown  in  Figure  6.5.  Once  in  the  IA  Builder,  the  user 
double-clicks  on  any  blank  area  to  bring  up  the  palette  of  display  icons.  The  Inter- 
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Figure  6.5:  Interactive  Animation  Display  for  AROD  Controller 


active  Animation  section  of  the  SystemBuild  manual  [Ref.  21]  and  the  AC100  User’s 
Guide  [Ref.  19]  have  details  on  all  of  the  available  icons  and  how  to  edit  them  for 
specific  needs.  The  user  then  selects  ’Load  RTF’  and  enters  the  name  of  the  ’.rtf’  file. 
The  user  then  connects  all  of  the  icons  to  the  respective  inputs  and  outputs  using 
the  same  connection  procedures  as  in  SystemBuild.  If  the  user  wants  to  display  an 
input  from  one  of  the  hardware  connections,  i.e.,  an  A/D  input,  an  extra  output  will 
have  to  be  added  to  the  model.  Inside  the  model  the  input  is  then  connected  to 
the  new  output  through  an  unity  gain  block.  Once  the  IA  picture  is  complete  and 
all  of  the  inputs  and  outputs  have  been  connected,  the  user  selects  save.  Additional 
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pictures  can  be  created  in  the  same  manner.  The  main  picture  should  be  saved  as 
’project  Jiame.pic’. 

Additional  pictures,  such  as  a  calibration  screen,  can  be  ’chained’  using 
the  ’process’  icon.  The  user  must  then  edit  the  ’animation. cfg’  file  and  add  ’file- 
name.pic’  under  the  ’PROCESS-PICTURES’  section  where  ’filename’  is  the  name 
of  the  ’chained’  picture.  The  IA  calibration  picture  used  for  the  AROD  is  shown  in 
Figure  6.8. 

2.  Hardware  Connection  Editor 

The  Hardware  Connection  Editor,  or  HCE,  screen  is  shown  in  Figure  6.6 
and  explained  in  the  AC  100  Reference  Manual  [Ref.  18).  The  individual  hardware 
modules  are  further  explained  in  the  AC  100  Supplemental  Reference  Manual  [Ref. 
22].  The  HCE  is  used  to  make  connections  to  hardware  and  also  to  the  I A  picture. 
All  connections  to  the  IA  picture  will  be  completed  automatically  and  should  not  be 
changed.  Before  invoking  the  HCE,  the  user  should  place  a  copy  of  the  file  ’c_c30.hce’ 
in  the  project  directory.  This  file  can  be  copied  from  the  ’c:\acl00c30\station’  direc¬ 
tory  on  the  AC  100.  The  first  screen  of  the  HCE  deals  with  inputs  to  the  model  and  the 
second  screen  deals  with  the  outputs.  Inputs  will  initially  show  ’MONITOR-INPUT’ 
as  the  ’type’  and  are  changed  by  selecting  ’Device-Type’.  If  the  correct  ’cx30.hce’ 
file  is  in  the  current  project  directory,  the  user  can  use  the  arrow  keys  or  the  mouse  to 
select  the  desired  hardware  for  connection.  The  module  field,  ’mod’,  will  change  to  1 
for  all  of  the  hardware  options  and  must  be  changed  to  the  correct  module  number. 
The  module  numbers  differ  according  to  which  C30  is  being  used  and  are  given  in 
Table  6.1.  Next  the  user  selects  the  channel  number,  ’ch#’  which  is  1  to  1000  for 
each  of  the  serial  ports  and  1  to  16  for  both  the  ’IP_HiADC’  and  the  ’IP_PWM’.  Each 
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Figure  6.6:  Hardware  Connection  Editor 


’IP-SERIAL’  module  has  two  serial  ports  referred  to  as  ’chan A’  and  ’chanB’.  The 
’ch#’  field  refers  to  the  data  channel.  Each  input  or  output  variable  will  require  an 
individual  channel.  The  AC100  Supplemental  Reference  Manual  [Ref.  22]  also  talks 
about  the  hardware  channel  number.  This  number  is  a  fixed  value  and  refers  to  the 
hardware  address  of  that  I/O  device.  The  outputs  are  initialized  to  ’NOJDEVICE’ 
and  are  connected  in  a  similar  manner. 
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TABLE  6.1:  C30  HARDWARE  MODULE  NUMBERS 


■i^ 

AC  100 

America 

IPJSERIAL 

2  or  3 

1  or  3 

IP-HiADC 

1 

IP-PWM 

4 

U! 

a.  Serial  Connections 

The  SERIAL  modules  can  be  used  for  input  and/or  output  [Ref.  22] 
pages  118-135.  The  serial  modules  were  used  for  the  Bluebird  hardware-in-the-loop 
test  and  the  AROD  Flight  Management  Unit  test.  The  Bluebird  has  an  Inertial 
Measuring  Unit  which  measures  linear  accelerations,  angular  rates,  and  euler  angles. 
This  information  is  available  to  the  controller  through  a  serial  port.  The  serial 
information  is  a  40  byte  string  of  hex  characters  terminated  by  a  return  character. 
This  format  differs  from  the  format  expected  by  the  C30,  however,  the  user  can  edit 
the  ’userjser.c’  file  and  specify  any  desired  format  for  the  data.  For  more  information 
on  serial  interfacing  with  the  IMU  see  [Ref.  23]. 

b.  Analog— to— Digital  Connections 

The  HiADC  module  is  used  for  input  only  [Ref.  22]  pages  110-117.  Any 
analog  voltage  signal  can  be  sampled  and  used  by  SystemBuild  in  a  digital  format. 
The  SystemBuild  block  diagram  can  then  use  the  input  in  units  of  volts,  or  convert 
the  number  to  some  other  units.  Section  3  below  discusses  the  conversion  from  volts 
to  degrees  used  for  the  AROD  hardware-in-the-loop  test. 
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c.  Pulse  Width  Modulation  Connections 


The  PWM  module  has  many  uses  for  both  input  and  output  [Ref.  22] 
pages  105-109.  Note  that  the  actual  name  of  this  module  is  ’IP.68332’  but  is  referred 
to  here  as  ’PWM’  since  this  is  the  only  mode  used  for  this  report.  In  the  PWM 
mode,  the  user  specifies  the  duty  cycle  as  the  output  from  the  SystemBuild  diagram. 
The  user  can  also  edit  the  ’c_c30.hce’  file  to  specify  the  frequency  of  the  pulses.  The 
refresh  frequency  is  integer  parameter  one  which  is  labeled  as  II  (column  10)  under 
the  output  section  of  this  file.  Figure  6.7  depicts  the  relevant  quantities  for  a  PWM 
signal. 
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Figure  6.7:  Timing  Example  for  Pulse  Width  Modulation 

The  spacing  from  the  leading  edge  of  one  pulse  to  the  next  is  called  the 
period  T,  and  is  the  inverse  of  the  refresh  frequency  or: 

T=y  (6.1) 

The  duty  cycle  is  calculated  as  the  percentage  of  time  the  pulse  is  ’high’  which  is  +5 
Volts  in  this  case. 

%  Duty  cycle  =  ^  (6.2) 
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The  refresh  frequency  for  the  AROD  hardware-in-the-ioop  test  was  chosen  to  be  equal 
to  the  controller  frequency  of  40  Hertz.  This  gives  a  period  T  of  0.025  seconds  or 
25  milli-seconds.  The  minimum  pulse  width  required  for  the  servos  is  approximately 
0.3  milli-seconds  so: 

0  3 

Min.  %  Duty  Cycle  =  ~  =  0.012  (6.3) 

25 

This  corresponds  to  a  vane  deflection  of  —100  degrees.  The  maximum  pulse  width 
required  for  a  +100  degree  deflection  is  approximately  2.4  milli-seconds  so: 

2  4 

Max.  %  Duty  Cycle  =  —  =  0.096  (6-4) 

25 

The  pulse  width  corresponding  to  a  centered  position,  or  zero  degrees  of  deflection, 
is  approximately  1.05  milli-seconds  so: 

1  05 

Centered  %  Duty  Cycle  =  =  0.041  (6.5) 

Zo 

Combining  these  gives: 

%  Duty  Cycle  =  0.00041  •  (Desired  deflection  in  degrees)  +  0.053  (6.6) 

The  algebraic  block  ’degrees_toJPWM’  included  in  each  of  the  four  vane  SuperBlocks 
and  shown  in  Figure  B.10  implements  Equation  6.6. 

3.  Sensor  Calibration 

Before  the  sensors  can  be  used  reliably  b'  *he  controller,  they  must  be 
calibrated.  Due  to  small  changes  in  the  operating  jitages  of  the  power  supply, 
calibration  is  required  each  time  the  controller  is  started.  For  the  original  hardware- 
in-the-loop  test,  a  separate  C  code  program  was  run  to  calibrate  the  actuator  sensors. 
Each  time  the  controller  is  started  the  I/O  devices  must  be  initialized.  This  results 
in  small  changes  in  the  measured  voltages  on  the  analog  to  digital  I/O  device  from 
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one  initialization  to  the  next.  For  this  reason  the  ’chained’  IA  picture  was  used  so 
that  the  I/O  would  not  have  to  be  re-initialized  after  calibration.  The  procedure  for 
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Figure  6.8:  Interactive  Animation  Calibration  Screen 

calibration  involves  measuring  the  sensed  voltage  for  vane  positions  of  -100  deg,  +100 
deg,  and  zero  degrees.  The  model  uses  these  measured  voltages  in  the  equation  used 
to  convert  the  measured  sensor  voltage  into  the  correct  vane  position  in  degrees: 

Vane  position  =  (Vmeai  -  V0)  x  — - — — -  (6.7) 

V +ioo  —  V_ioo 

After  starting  the  controller,  the  calibration  routine  is  completed  as  follows: 


•  The  user  clicks  on  the  ’calibrate’  button  to  bring  up  the  calibration  screen. 


•  Next  the  user  clicks  on  the  ’Cal_mode’  switch  which  connects  the  calibration 
inputs  to  the  actuators. 

•  The  voltage  for  0  degrees  is  then  entered  in  the  ’VO’  input  for  each  vane. 

•  Next  the  position  inputs  are  all  changed  to  +100  degrees  and  the  displayed 
voltage  is  input  with  the  ’Plus  100’  bar  for  each  vane. 

•  Finally,  the  position  inputs  are  all  changed  to  -100  degrees  and  the  ’Minus  100’ 
inputs  are  changed  accordingly. 

The  user  can  then  switch  the  ’Cal_Mode’  switch  back  to  ’off’  and  click  on  the  ’Return’ 
button. 

4.  Data  Acquisition  Editor 

A  very  useful  feature  of  the  AC100  is  real-time  data  acquisition.  The  user 
can  record  any  or  all  of  the  inputs  and  outputs  to  a  C30  project.  In  this  way,  the 
user  can  get  a  very  detailed  analysis  of  the  performance  of  a  particular  model  and/or 
controller.  The  user  first  selects  ’Data  Acquisition  Editor’  from  the  AC100  GUI, 
Figure  6.4.  The  user  will  be  presented  with  the  screen  shown  in  Figure  6.9.  To  record 
an  input,  simply  select  ’ON’  under  the  ’setting’  column.  If  the  ’decimationJfactor’  is 
left  at  T’  then  the  value  of  that  input  will  be  recorded  every  time  step.  To  select  an 
output,  toggle  the  ’Display’  selector  at  the  bottom  of  the  screen  from  ’SB JNPUTS’ 
to  ’SB.OUTPUTS’.  When  all  of  the  desired  inputs  and  outputs  have  been  selected, 
click  ’DONE’.  The  AC100  GUI  will  return. 

Once  the  user  selects  ’Download  and  Run’,  the  ’AC100  rtmpg  Control  Win¬ 
dow’  and  the  Interactive  Animation  display,  Figure  6.5,  will  appear.  To  start  record¬ 
ing  data,  the  user  selects  ’START  DATA  ACQUISITION’.  This  will  create  a  file  in 
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Figure  6.9:  Data  Acquisition  Editor 
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the  project  directory  with  the  project  name  and  ’.l.raw’  appended.  The  number  will 
be  automatically  incremented  so  that  many  data  files  may  be  collected.  The  but¬ 
ton  will  also  change  to  ’STOP  DATA  ACQUISITION’.  If  data  acquisition  is  started 
before  ’Start  Controller’,  the  data  acquisition  will  begin  with  the  first  time  step  of 
the  controller.  Data  acquisition  stops  automatically  if  the  controller  is  stopped  or 
rebooted. 

After  selecting  ’REBOOT  CONTROLLER’,  the  user  is  returned  to  the 
AC100  GUI.  The  user  then  selects  ’Convert  raw  data’.  This  will  create  a  file  with 
the  same  name  as  the  ’.raw’  file  with  ’.dat’  as  the  file  extension.  This  data  file  can 
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then  be  loaded  directly  into  MATRIX*.  The  MATRIX*  variable  names  will  be  the 
same  as  those  used  as  the  input  or  output  names  in  the  SystemBuild  model.  These 
variables  will  be  vectors  with  lengths  depending  on  the  amount  of  time  that  data  was 
recorded.  Plots  of  these  variables  are  made  the  same  as  for  any  MATRIX*  variable. 

C.  CONNECTING  THE  HARDWARE 

Now  that  all  of  the  software  tools  have  been  developed,  the  hardware  must  be 
physically  connected  to  the  control  computer.  Figure  6.10  shows  the  complete  setup 
for  the  hardware-in-the-loop  test  using  the  AC100  Model  C30.  The  SPARC  work¬ 
station  is  the  user’s  main  interface  with  the  controller.  The  Interactive  Animation 
picture  is  updated  via  the  ethernet  connection  with  the  C30.  The  C30  runs  the 
controller,  the  aircraft  model,  and  interfaces  with  all  of  the  hardware. 

The  wiring  harness  was  developed  so  that  the  first  test  flight  of  AROD  could 
be  done  with  the  control  computer  remaining  on  the  ground  and  connected  to  the 
AROD  with  a  tether.  The  wiring  harness  and  tether  are  designed  to  supply  power 
to  the  AROD  and  to  provide  all  of  the  control  signals  and  return  all  of  the  sensor 
outputs.  Figure  6.11  shows  the  connector  end  of  the  tether.  For  this  test,  only  the  5 
volt  power  lines  and  the  vane  signals  were  used. 

The  servo  motors  have  two  sets  of  wires  emerging  from  the  case.  Each  set 
contains  a  red,  white,  and  black  wire.  The  wires  attached  to  the  narrow  side  of  the 
servos  are  the  input  wires  and  the  wires  attached  to  the  wide  side  are  the  sensor 
outputs.  Table  6.2  lists  the  function  of  each  of  these  wires. 

The  pin  diagrams  for  each  of  the  C30  Modules  are  in  [Ref.  22].  Figure  6.12 
shows  the  complete  wiring  for  the  AROD  hardware-in-the-loop  test  on  the  C30.  The 
wiring  harness  box  is  a  PC  shell  containing  screw  terminal  blocks  and  a  PC  power 
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Figure  6.10:  AC  100  Model  C30  Hardware-In-The— Loop  Setup 

supply  as  well  as  a  24  Volt  power  supply.  The  wire  connections  internal  to  the  wiring 
harness  are  not  shown. 
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Figure  6.11:  Connector  on  end  of  Wiring  Harness  Tether 


TABLE  6.2:  SERVO  MOTOR  WIRING 


Control  Inputs 

Sensor  Outputs 

Red 

+5  Volts 

High  Tap 

White 

PWM  Input 

Center  Tap 

Black 

Ground 

Ground 
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Figure  6.12:  AC100  Model  C30  Hardware-In-The-Loop  Test  Wiring  Dia¬ 
gram 
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VII.  RESULTS,  CONCLUSIONS,  AND 
RECOMMENDATIONS 

A.  HARDWARE-IN-THE-LOOP  TEST  RESULTS 

The  hardware-in-the-loop  test  of  N.  Sivashankar’s  controller  showed  the  con¬ 
troller  to  be  unstable.  Analyzing  the  actuators  as  discussed  in  Chapter  V  revealed 
that  the  controller  was  changing  the  commanded  position  of  the  vanes  faster  than 
the  vanes  could  respond.  The  controller  gain  was  re-computed  using  the  original  syn¬ 
thesis  model  and  the  H,*,  theory  procedure  outlined  in  Chapter  IV  Section  A.  The 
cost  function  weighting  matrices  were  adjusted  to  reduce  the  control  loop  bandwidth 
to  less  than  2  radians  to  account  for  the  limited  performance  of  the  actuators.  The 
resulting  bandwidth  for  the  control  and  command  loops  are  compared  to  the  originals 
in  Figure  7.1.  The  first  three  sub-plots  show  the  old  (solid)  and  new  (dashed)  control 
loop  bandwidth.  The  second  three  sub-plots  show  the  old  and  new  command  loop 
bandwidth. 

The  new  control  gain  was  then  entered  into  the  controller  and  tested.  The 
hardware-in-the-loop  test  of  the  new  controller  was  successful  and  showed  slower 
responses  to  disturbances  as  expected.  For  a  comparison,  the  new  controller  was 
subjected  to  the  same  series  of  disturbances  a s  the  original  controller.  Figure  7.2 
shows  the  SystemBuild  disturbance  rejection  plot  from  the  original  controller.  The 
hardware-in-the-loop  disturbance  rejection  plot  is  similar  with  some  noise  [Ref.  3] 
but  was  not  available  for  reproduction  in  this  report.  The  disturbances  introduced 
for  all  of  these  tests  are  listed  in  Table  7.1.  Figure  7.3  shows  the  pitch  and  yaw  errors 
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recorded  from  the  hardware-in- the-loop  test  of  the  new  controller.  Notice  that  there 
is  relatively  little  noise  in  the  new  controller  due  to  the  new  sensor  design. 

TABLE  7.1:  PITCH  AND  YAW  DISTURBANCES  IN  RADIANS 


Time  (seconds) 

0 

4 

9 

15 

Pitch  Disturbance 

0.1 

0.2 

0 

0.2 

Yaw  Disturbance 

-0.1 

0 

-0.2 

0.2 

B.  CONCLUSIONS 

Based  on  the  data  presented  in  this  thesis  the  following  conclusions  are  drawn: 

•  Automation  using  the  AC100  Model  C30  dramatically  improves  the  time  to 
first  prototype.  Valuable  time  is  saved  by  not  having  to  write  code  for  the 
control  computer  and  the  hardware  I/O  drivers.  The  user  only  needs  a  basic 
understanding  of  the  hardware  and  it’s  requirements.  All  required  code  is 
generated  automatically  by  the  AC  100  software. 

•  Improvements  to  the  model  or  controller  can  be  implemented  and  tested  imme¬ 
diately.  For  the  same  reasons  as  above,  any  changes  made  at  the  block  diagram 
level  can  be  tested  immediately  with  a  few  mouse  clicks. 

•  Real-time  data  acquisition  allows  for  detailed  analysis  of  test  results.  Since  all 
of  the  inputs  and  outputs  can  be  recorded  at  each  time  step,  the  data  can  be 
scrutinized  thoroughly  after  a  test.  This  is  a  tremendous  help  when  trying  to 
find  errors  created  by  improper  timing. 

•  Hardware-in-the-loop  testing  does  not  fully  validate  a  controller  if  the  test  is 
not  performed  real-time.  The  original  controller  was  considered  stable  after 
initial  hardware-in-the-loop  testing,  but  was  not  stable  when  tested  real-time. 


C.  RECOMMENDATIONS 

Considering  the  conclusions  introduced  above  and  the  experience  gained  while 
conducting  this  thesis,  the  following  recommendations  are  made: 

•  Investigate  sending  IA  data  to  additional  ethernet  address  and  capturing  data 
for  Virtual  Prototying  on  Designer’s  Workbench.  Previous  thesis  work  has 
demonstrated  the  extraordinary  benefits  of  Virtual  Prototyping.  Presently  the 
data  from  an  AC100  Model  C30  hardware-in-the-loop  test  would  have  to  be 
recorded  and  then  moved  to  another  file  for  use  by  Designer’s  Workbench. 
Sending  data  directly  from  the  AC100  Model  C30  to  Designer’s  Workbench 
would  allow  real-time  3-Dimensional  representation  of  the  hardware-in-the-loop 
test  data. 

•  Investigate  using  graphics  programs  with  C30  for  field  display  of  data.  Cur¬ 
rently  the  AC100  Model  C30  sends  all  of  the  test  data  to  the  workstation  for 
display.  The  AC  100  Model  C30  would  be  very  useful  for  a  tethered  flight  test 
of  the  AROD,  however,  this  would  currently  require  a  portable  workstation  to 
display  the  data  from  the  AC  100  Model  C30.  The  data  could  easily  be  dis¬ 
played  on  the  AC100  Model  C30  display  with  the  use  of  a  DOS  or  Windows 
graphics  interface. 

•  Incorporate  the  AC100  Model  C30  into  the  avionics  design  course  work.  Valu¬ 
able  experience  is  gained  when  testing  a  controller  with  hardware-in-the-loop  . 
Students  learn  to  consider  all  of  the  requirements  for  interfacing  such  as: 

-  signal  conversion  (i.e.,  analog  to  digital,  volts  to  degrees,  degrees  to  PWM, 
etc.) 
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power  requirements 

timing  (when  control  signals  are  generated  vice  when  the  sensor  output  is 
available) 

interference  (interaction  of  control  signals,  Radio  Frequency  interference) 
data  bandwidth  (information  required  verses  information  available 
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Figure  7.1:  Comparison  of  Bandwidth  for  Controllers 
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APPENDIX  A 
MATLAB  FILES 


A.  GETJXDOT.M 

function  [  x.dot]  =  get_xdot(invect) 

% 

%  Function  computes  x.dot  given  an  input  vector  which  is  x  and  u_c 
%  muxed  together.  u_c  is  first  four  and  x  is  last  nine.  The  inputs 
%  order  is  elevator,  rudder,  aileron,  rpmjsetting.  The  states  are 
%  u,  v,  w,  p,  q,  r,  phi,  theta,  psi. 

% 

%%%%%%%%  First  step  is  to  demux  the  input  vector 

u_c=invect(l:4); 

%  u_c(l)=delta  e  (elevator) 

%  u_c(2)=delta  r  (rudder) 

%  u_c(3)=delta  a  (aileron) 

drpm  =  u_c(4);  %(throttle) 

v=invect(5:7); 

%  v(l)=u  (x  velocity) 

%  v(2)=v  (y  velocity) 

%  v(3)=w  (z  velocity) 

omega= invect  ( 8:10); 
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p=omega(l);  %(roll  rate) 
q=omega(2);  %(pitch  rate) 
r=omega(3);  %(yaw  rate) 

lambda=invect(  11:13); 
phi=lambda(l);  %(bank  angle) 
theta=lambda(2);  %(pitch  angle) 
psi=lambda(3);  %(yaw  angle) 

x=[  v;  omega;  lambda;  ]  ; 

%%%%%%%%  Next  get  constant  values  for: 

%  m,Ib,Ir,S,Cfo,dCfdx,dCfdd,Ml,rho,Ar,g 

% 

constval, - 

%  constval  is  a  Matlab  script  file,  not  a  function,  and  sets  the 
%  values  in  the  Matlab  environment  for  use  by  all  functions. 

%%%%%%%%  Form  omega  cross  matrix  and  compute  Vt  and  q 

wx=[  0  -r  q;  r  0  -p;  -q  p  0  ]  ; 

Vt=sqrt(v(l)A  2+v(2)A  ?+v(3)A  2); 
qbar=.5*  rho*  VtA  2; 

%%%%%%%%  Form  sine  and  cosine  abreviations 

% 

ch=cos(phi); 

sh=sin(phi); 
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ct=cos(theta); 

st=sin(theta); 

cs=cos(psi); 

ss=sin(psi); 

%%%%%%%%  Form  force  due  to  gravity 

%  B  U 

%  R  *  F  =  force  due  to  gravity,  moment  =  0 

%  U  g 

% 

%  2-3-1  rotation 

% 

RubFg=[  -cs*  st*  g 

(ch*  ss*  st+sh*  ct)*  g 
(ch*  ct-sh*  ss*  st)*  g  ]  ; 

%%%%%%%%  Form  Rwb  (transform  wind  coordinates  to  body 

alpha=asin(v(2)); 

beta=-asin(v(3)); 

Rwb=[  cos(alpha)*  cos(beta)  -cos(alpha)*  sin(beta)  -sin(alpha) 

sin(beta)  cos(beta)  0 

sin(alpha)*  cos(beta)  -sin(alpha)*  sin(beta)  cos(alpha)  ]  ; 

%%%%%%%%  System  is  of  the  form 

% 

%  x  =  Ax  +  Bu  +  C  where  u  is  the  control  inputs  and 
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C  is  a  combination  of  gravity  and 
other  influences 


% 

% 

% 

%%%%  Form  ”A”  matrix 

% 

%%%%  USING  THRUST  VS  RPM  FROM  BOB  STONEY’S  TEST  RUNS 

% 

T=0.0297*  drpm-104.7; 

% 

Vi=sqrt(T/2/Ar/rho); 

% 

%  NOTE:  derivatives  are  non-dimentionalized  with  qi  (induced  velocity) 

%  so  add  u  to  the  induced  velocity  for  total  q 

% 

qt=.5*  rho*  (v(l)+Vi)A  2; 

% 

It=lb-flr; 

O=zeros(3,3); 

I=eye(3); 

% 

%  The  generic  ‘A‘matrix  would  be: 

%  A=([  -wx  O;  O  -It\  (wx*  It)]  -f  [  (I/m)*  Rwb  0;  0  It\  Rwb  ]  *  q*  S*  dCfdx* 
Ml); 

% 

A=[  -wx  0;  0  -It\  (wx*  It)]  ; 
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% 

%%%%  Form  ”B”  matrix 

% 

%  Note:  control  surface  derivatives  are  non-dimentionalized  using 
%  characteristic  lengths  from  rotor 
% 

B 1 =[  (I/m)*  Rwb  0;  0  It\  I  ]  *  qt*  Sd*  dCfdd; 

% 

%%%%%  LT  relates  the  duct  swirl  to  the  moment  1  produced  by  thrust 

% 

LT=-0.0542*  T-0.9138; 
wr=[  drpm*  2*  pi/60;0;0]  ; 

% 

B2=[  T/m;  0;  0;  -It\  ([  LT;  0;  0;]  +(wx*  Ir*  wr))  ]  ; 

% 

%%%%  Form  ”Cr>  matrix 

% 

%  Generic  ‘C‘matrix  would  be 

%  C=[  (I/m)*  RubFg;  0;0;0;  ]  +[  (I/m)*  Rwb  O;  0  It\  Rwb  ]  *  qbar*  S*  Cfo; 

% 

C=[  RubFg;  0;0;0;  ]  ; 

% 

%%%%  Form  Drag  matrix 

% 

%  Note:  this  is  not  aerodynamic  drag,  this  is  tin  estimate  of  the 
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%  parasitic  drag  elements. 

% 

sb=6.7708; 

s=S(2,2); 

su=sign(v(l)); 

sv=sign(v(2)); 

sw=sign(v(3)); 

sp=sign(p); 

sq=sign(q); 

sr=sign(r); 

Sdrag=diag([  su*  Ar,sv*  sb,sw*  (s+sb),sp*  .5*  s,sq*  .7*  (s+sb),sr*  .5*  sb]  ) 
Vm=[  (v.A  2)/m;  It\  (omega.A  2)  ]  ; 

D=rho*  diag(Cfo)*  Sdrag*  Vm; 

%%%%%%%%  Form  lambda  dot  using  2-3-1  rotation 

% 

ldot=[  p-q*  ch*  ss/cs+r*  sh*  ss/cs 
q*  ch/cs-r*  sh/cs 
q*  sh+r*  ch  ]  ; 

%%%%%%%%  Form  totals 

% 

vw_dot=A*  [  v;  omega  ]  +B1*  u_c(l:3)+B2-fC-|-D; 
x_dot=[  vw_dot;  ldot;  ]  ; 
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B.  CONSTVAL.M 


% 

%  [  m,Ib,Ir,S,Sd,Cfo,dCfdx,dCfdd,Ml,rho,Ar,g] 

% 

%  This  file  returns  all  of  the  constants  for  the  arod  EOM 
%  Hover  condition  =)  all  aero  derivatives  are  zero 

%  Total  body  mass 
m=2.6419;  %  slugs 

%  Body  mass  moment  of  inertia 

Ib=[  1.2312  0  0;  0  3.9548  0;  0  0  3.9825  ]  ;  %slug  ft  A  2 

%  Prop  mass  moment  of  inertia 

Ir=[  0.00898  0  0;  0  0.0045  0;  0  0  0.0045  ]  ;  %slug  ft  A  2 

%  Standard  length  matrix  for  wings 
ss=9.4444;  bw=5.7;  cbarw=2.165; 

S=diag([  -ss,ss,-ss,ss*  bw,ss*  cbarw,ss*  bw]  ); 

%  Standard  length  matrix  for  control  surfaces 
sp=pi;  bp=l;  cbarp=l; 

Sd=diag([  -sp,sp,-sp,sp*  bp,sp*  cbarp,sp*  bp]  ); 

%  Cfo  (used  as  a  drag  term  in  all  three  axes 
Cfo=[  -.015;  -.015;  -.015;  -0.015;  -0.015;  -0.015;  ]  ; 


%  dCf/dj 
dCfdx=0; 


%  dCf/dx_dot=0  for  this  model 
%  dCfdxd=[  ]  ; 

%  dCf/ddelta 

dCfdd=[  zeros(3,3);  0  0  1.438;  -1.233  0  0;  0  -1.233  0  ]  ; 

%  Ml 
Vt=l; 

Ml=diag([  l/Vt,l/Vt,l/Vt,bw/(2*  Vt),cbarw/(2*  Vt),bw/(2*  Vt)]  ); 
%  rho 

rho=. 002377;  %slugs/ftA  3 

%  area 
R=l; 

Ar=pi*  R; 

%  gravity 

6=32.174;  %ft/secA  2 
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APPENDIX  B 

MATRIX*  BLOCK  DIAGRAMS 

A.  AROD  SystemBuild  BLOCK  DIAGRAMS 

The  AROD  SystemBuild  block  diagram  contains  the  following  SuperBlocks: 

•  actuators:  Figure  B.l  shows  the  SuperBlock  containing  4  actuator  SuperBlocks, 
one  for  each  vane. 

•  actuator.l:  Figure  B.2  shows  the  actuator  model  for  the  first  vane  and  is 
identical  to  the  other  vane  actuators. 

•  actuator_2:  Not  shown. 

•  actuator-3:  Not  shown. 

•  actuator-4:  Not  shown. 

•  ang_velocity_eq:  Figure  B.3  shows  the  SuperBlock  for  the  angular  velocity 
equations.  The  values  for  the  body  and  rotor  inertia  matrices  are  listed  in 
Table  2.1. 

•  dcont_wind:  Figure  B.4  shows  the  controller  SuperBlock  for  the  AROD.  The 
saturation  block  limits  the  throw  of  the  vanes  to  ±15  degrees.  The  two  algebraic 
blocks  convert  the  command  signals  to  vanes  signals  in  degrees,  and  the  vane 
signals  back  to  command  signals  in  radians  respectively. 

•  filters:  Figure  B.5  shows  the  four  anti-aliasing  filters  discussed  in  Chapter  V 
Section  E.  The  values  for  the  four  vane  filters  are  given  in  Equation  5.8. 
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•  integ_ang-vel:  Not  shown. 


•  integJin.vel:  Not  shown. 

•  Integjsim:  This  SuperBlock  contains  the  SuperBlocks  ’integ-ang.vel’,  ’in- 
tegJin_vel’,  and  ’int^ang-sim’.  Each  of  these  SuperBlocks  contain  three  dis¬ 
crete  integrators  as  shown  in  Figure  3.2  with  the  appropriate  initial  values. 
The  ’int -ang_sim’  SuperBlock  also  contains  two  sum  blocks  to  add  in  the  per¬ 
turbations  for  0  and  ip. 

•  int_ang_sim:  Not  shown. 

•  kinematics:  Figure  B.6  shows  the  kinematics  SuperBlock  which  contains  the 
’lin.velocityjeq’,  ’ang.velocityjeq’,  and  ’L_dot_eq’  SuperBlocks. 

•  lin_velocity_eq:  Figure  B.7  shows  the  equations  for  the  linear  forces  acting 
on  the  aircraft.  The  ’T-value’  SuperBlock  contains  Equation  3.1  and  block  95 
is  the  force  due  to  gravity. 

•  L_dot_eq:  Not  shown.  This  SuperBlock  is  an  implementation  of  Equation  2.58. 

•  l_mjn_compute:  Figure  B.8  computes  the  angular  momentum  terms.  Blocks 
5,  6,  and  98  contain  the  appropriate  stability  derivatives  and  block  7  includes 
the  moment  due  to  propeller  thrust  given  in  Equation  3.2. 

•  nl_tst4_hw:  Figure  B.9  shows  the  top  level  SuperBlock  for  the  hardware-in- 
the-loop  test.  The  inputs  and  outputs  from  this  SuperBlock  are  listed  in  the 
’nLtst4_hw.rtf’  file  and  used  in  the  Hardware  Connection  Editor. 

•  T  .value:  Not  shown.  This  SuperBlock  is  Equation  3.1. 

I 

1 
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•  vanel:  Figure  B.10  shows  the  Superblock  for  vane  one  and  is  identical  to  the 
other  three  SuperBlocks.  Block  6  shows  the  conversion  from  degrees  to  percent 
duty  cycle  discussed  in  Section  c  of  Chapter  VI.  Block  4  is  the  algebraic  block 
discussed  in  Section  3  of  Chapter  VI. 

•  vane2:  Not  shown. 

•  vane3:  Not  shown. 

•  vane4:  Not  shown. 

•  vane4x:  Figure  B.ll  shows  the  ’vane4x’  SuperBlock  which  contains  a  Su- 
perBlock  for  each  of  the  four  vanes  and  the  ’filters’  SuperBlock. 
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Discratt  SuparBlock 
actuators 
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0.025  I  0.025 


Dlscrat*  SuperBlock  Saqiling  Inttml  First  Saopis  Ext. Inputs  Ext. Outputs  Ensbls 


Discret* 
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Discreet  SuptrBlock  Sacpling  Interval  First  Sasplt  Ext. Inputs  Ext .Outputs 


Figure  B.4:  Discrete  Controller  Superblock 
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Di«cr*t«  SupsrBlock  Sasylinj  Intsrnl  Fir«t  Saaplt  Ext. Inputs  Ext. Outputs  Enabl* 
filtcs _ 1.0000D-03 _ 0. _ j  4  Pu-^t 


Figure  B.5:  Anti-Aliasing  Filters  Superblock 
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Di»cr»t#  Sup«rBloc)t  Saaplin?  Interval  First  Saapl*  Eat. Inputs  Ext. Output! 
lip_T«locity_«q _ 0.0250 _  0.  11  3 


Discrsts  SupsrBlocfc  Sailing  Inttml  First  Ssnpls  Ext. Inputs  Ext  .Outputs 


Figure  B.8:  Compute  l,m,  and  n  Superblock 
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U3*U4*U5 


Discrst#  SupsrBlock  Sanplinj  Intsrval  First  Saspls  Ext. Inputs  Ext. Outputs  Biabl* 
nl_tst4J*  0.0250  0.  35  31  Pirsnt 


Figure  B.9:  AROD  Model  and  Controller  Superblock 
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BLOCK 


Discrtt* 


Figure  B.10:  Single  Vane  Superblock 


Discrtts  SupsrBlock  Sampling  Intsml  Fine  Ssgpls  Ext. Inputs  Exe .Outputs 
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